reiher@ucla-cs.UUCP (04/03/87)
I recently posted a message to this newsgroup asking for experiences
with unusual mounting strategies, those in which file systems would be
mounted in places in the file hierarchy other than their usual position,
or those in which two or more file systems would (at different times) be
mounted in the same place in the file hierarchy. I forgot to mention that
I would summarize results to the net, and, since I've had several requests
to do so, the responses follow.
For those who are only interested in a true summary, the majority of the
respondents had unusual mount patterns for two basic cases: portable
media, like floppies, and dealing with disasters/emergencies/unusual
cases. The former, of course, would have to be considered in any plan to
change what sorts of mounting are permissible. The latter probably wouldn't
cause any problems if the superuser were able to override any restrictions,
or work around them in some simple way.
A few people indicated that they used unusual mounting patterns for
other purposes, such as testing of software. For more information about
these cases, see the actual messages.
Many thanks to all who responded. I tried to respond personally to each
message that came in, but lots of my responses got bounced by the mailer.
Anyone particularly interested in why I care about this subject is welcome
to correspond with me. Basically, it involves research in distributed systems,
and has to do with cases of replicated file systems, and failure and
partitionings. Again, thanks.
Peter Reiher
reiher@LOCUS.UCLA.EDU
{...ucbvax,sdcrdcf}!ucla-cs!reiher
--------------------------------------------------------------------------------
From: woods@hao.ucar.edu (Greg Woods)
Limiting, OK, but I'd hate to lose the ability to mount a file system
somewhere else. We do not do this when the system is operating normally,
but there are some times when we HAVE done it. Typically they involve
recovering from disasters or installing new devices. They are:
1) After a head crash wiped out all the data on the root disk, it was
handy to boot off a different device, and then mount the old root device
at a different point in the tree, so that the data on it can be restored
from backup tapes. If I couldn't mount that device anywhere but on /,
I'd be hosed in this situation.
2) Our /usr/spool partition got wiped out. IN this case, I turned off
netnews and uucp logons, brought the system up without mounting /usr/spool,
mounted the old /usr/spool at a different point, and proceeded to try and
repair the damage without the users all being stuck waiting for me (the only
thing they lose is their saved mail, which comes back when I restore the
old mount structure). Having /usr/spool become just a directory under
/usr at least allows things like line printer daemons to function.
3) When installing a new disk. I mounted it on a scratch file system
and invited users to have at it. No quotas or scrubbers. When the time
came to fully make use of the new disk, the /usr partition was moved
over there, and the old disk repartitioned so that the old /usr
became part of a different partition.
--Greg
-------------------------------------------------
From: Malcolm Slaney <spar!malcolm@decwrl.DEC.COM>
We have two file systems (/ufont and /dfont which are the upstairs and
downstairs copies of our font directories) which we would like to be able
to mount on /font. The idea is that if the downstairs server goes down then
we would like to be have the downstairs machines mount the upstairs
font file system.
I'm not sure if this is an example of what you were talking about....
Malcolm
----------------------------------------------------
From: cs.ames!ptsfa!jmc
We mount /usr/src as a separate filesystem - this is the only case
so far but anytime a filesystem gets too large and I want to split
it, I may want to isolate a sub-directory as its own filesystem.
This is a specialized not a general purpose use of subdirectory mounts.
-----------------------------------------------------
From: kdw1%sphinx.UChicago.BITNET@BERKELEY.EDU(Keith Waclena)
Just a quick comment (we're running SysVr2.? on an AT&T 3B5). We don't
swap file systems very often, but we have a couple times (and I think
we soon will again), and it's been crucial. However, if Unix were
designed differently, we wouldn't have to do these things.
We have a lot of disk, and so keep a free unused large partition for
flexibility. For example, some months ago we ran out of inodes on
/usr, and to fix the problem without mucking about with tapes we just
mounted the free partition in /mnt, created a filesystem on it with
lots more inodes, dd'd /usr to it and and then swapped them around.
We swapped 'em instead of copying the new one onto the old one so that
we could play with it for a while and see if our choice of inode count
was okay. Eventually we moved the new /usr to its original partition
(after an update) because we preferred the size of that partition.
I realize this sort of thing is just patching. Obviously it would be
nice if you could up the inode count without so much trouble.
On a smaller Unix machine (a Convergent Technologies Miniframe running
their port of System V) we mount floppy file-systems frequently (cause
there's not much disk). Usually they're mounted under /mnt, but not
always. Anyway, having /mnt be demountable *is* generally useful.
Keith Waclena BITNET: xrtkdw1@uchimvs1.bitnet
University of Chicago UUCP: ...ihnp4!gargoyle!sphinx!kdw1
Graduate Library School Internet: keith@gargoyle.uchicago.edu
---------------------------------------------------------
From: John Redden <ames!redden@ttidca>
I also would be curious as to who uses "divergent" mount points in the file
system.
At TTI as you may know, we have a HEAVILY cross mounted NFS file system, so
this is also a great interest to me.
Most of the time we use odd ball mounts for restores; when we are testing
in parallel a new fs and when we have to do a cut over and conversion (for
obvious reasons of parallel operation without path name sensitivity).
John Redden systems group technical manager.
trwrb!ttidca!redden
---------------------------------------------------------
From: cs.rutgers!seismo!epiwrl!spook!hank
All MASSCOMP machines have a directory in the standard software
distribution called /mnt which is used to mount temporary file
systems. This is most often used for file system floppies. I have
also used a flexible mounting strategy for anothter purpose. I have a
demo userid which is used for demo programs. A certain software
vendor has a very large package which will not fit on the /usr/demo
partition along with all of the other stuff that is there. So what I
did was to load it onto my /tmp partition call it /tmp/software unmount
/tmp unmount /usr/demo and mount /tmp on /usr/demo. The demo programs
on the /tmp/software directory all assume that they reside on
/usr/demo/software so everything works out ok. When the demo is over
the /tmp partition goes back onto /tmp. Is this clear? My system has
3 disks 1 of which is a Fujitsu Eagle with 387 MB of space. The Eagle
is split up into 4 user defined partitions and /tmp is the largest
partition. Obviously this is all a kludge but it works as long as I
don't leave things scrambled up like this for too long.
If you are making policy keep removable media in mind. It is still
popular with many users. Many of these users may use the same data
partition mounted in different user directories depending on who is
using the disk. For instance the producer of the data may mount a
removable drive on his own local directory write on it and then
unmount it and give it to a consumer who again mounts it locally and
reads what was writ.
------------------------------------------------------------
From: cs.rutgers!seismo!gatech!itm!danny
Well, we do have a kinda wierd setup. Before our current system,
we had /u mounted on a CDC 9772 850M disk. Now, we have two Fujitsu
Swallows (260M each). We therefore had to split /u somehow. The
following illustrates the current situation; the output of mount(8),
non-informative lines elded:
/dev/0xd0e on /u type 4.2 (rw,noquota)
/dev/0xd1c on /u/db type 4.2 (rw,noquota)
So, this means that /u must be mounted before /u/db, and, of
course, that /u/db must be unmounted first. We've never encountered
any problems with this scheme (under 4.2).
Now, under System V, we found that the shutdown command tried to
unmount in the opposite order than what was needed. It used the output
of mount(8), with a sed script, and produced the unmount commands.
If one changed that to use the output of df(1) (and, of course, a
different sed command), it unmounted in the proper order.
Daniel S. Cox
({seismo!gatech|ihnp4!akgua}!itm!danny)
--------------------------------------------------------------
From: rocksanne!z@CS.ROCHESTER.EDU (Jim Ziobro)
We never got a service contract on a couple of our drives. One disk was used
for swapping, /tmp, and other unimportant junk. When one of the disks went
down then we would move /tmp to an "a" partion on another disk and also
swap to another disk.
The plus to that method is that we saved a lot in service charges.
--------------------------------------------------------------
From: aglew@gswd-vms.ARPA (Andy Glew)
Static work patterns are fine for big machines.
But have you ever used UNIX on a system with floppies?
You tend to move mount points around a lot,
when you're mounting from a floppy.
On the other hand, even for floppies I would expect that you nearly
always mount a given floppy at a given point. So, the static association
of disk with mount point would be alright, if the association were
recorded on the media, not in some sort of configuration file.
I used to use small UNIX systems a lot, but now I have regressed to working
on minis. Around here we do a lot of development, testing out new packages,
etc. Most drives are statically mapped to the same mount point,.
But we have a set of disk packs that we use to test software packages that
are too large to fit in other partitions; these packs have a habit of changing
their mount point. Usually this is done on a weekly basis, but when you get
too many developer's wanting to test simultaneously, it will be done
an an almost hourly basis.
----------------------------------------------------------
From: Irving Reid <cs.rutgers!cbosgd!ihnp4!sask!reid>
I run a PDP-11 (DEC Pro 350) running Unix V7 on a 10 meg hard disk with two
RX50 floppies. I don't do much programming on it (because I have access to
a Pyramid and a Vax 8600 at school), but being able to mount whatever floppy
my current project is on, at some known place, is a luxury I don't want to
give up.
I suppose I could create a separate mount point for each floppy I might want
to use, but that could get ugly in the long run (Damn. Where was I supposed
to mount _this_ one?).
- irving reid -
reid@sask.uucp {alberta, ihnp4, utcsri}!sask!reid
--------------------------------------------------------
From: hamilton@uxc.cso.uiuc.edu (Wayne Hamilton)
the first exception that comes to mind are systems with floppy
drives. i used to use such a system, and i would mount different
floppy filesystems on the same directory (/tmp/f or somesuch).
wayne hamilton
U of Il and US Army Corps of Engineers CERL
UUCP: {ihnp4,seismo,pur-ee,convex}!uiucuxc!hamilton
ARPA: hamilton%uxc.cso.uiuc.edu USMail: Box 476, Urbana, IL 61801
CSNET: hamilton%uxc@uiuc.csnet Phone: (217)333-8703
CIS: [73047,544] PLink: w hamilton
-------------------------------------------------------
From: mangler@csvax.caltech.edu (System Mangler)
Ok, we have this pair of vax-750's with a stack of dual-ported disks
sitting between them, and they both mount all the disks. Of course
each disk is read-only on (at least) one side. A given filesystem
may be mounted as "/" on one side, and "/vlsi" on the other. If one
machine dies, the other gets to mount all the filesystems read-write.
/usr is a funny case, they both mount it read-only, and every now
and then we update it from the "master copy" on the 780 that has
/usr/src. The way we do this currently is "rsh dump | restore"
on an overlapping partition mounted read-write (gag) so we don't
have to umount /usr (which would require killing everything).
Most of the time the machines actually stay up after doing this,
unless we've changed something that some daemon keeps open.
Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck
--------------------------------------------------------
From: Root Boy Jim <rbj@icst-cmr.ARPA>
I always mount everything directly off the root, and use symbolic links
to point things to the right places. That way, I can unmount /usr without
having to unmount /usr/src. Actually, /usr has been sucked into the root
filesystem on our machines.
(Root Boy) Jim "Just Say Yes" Cottrell <rbj@icst-cmr.arpa>
Peter Reiher
reiher@LOCUS.UCLA.EDU
{...ucbvax,sdcrdcf}!ucla-cs!reiher