gkishida@orion.cf.uci.edu (Gregg Kishida) (07/23/89)
I am currenly managing a variety of systems, all of which seem to be in one way or another incompatable with each others implementation of yellow pages (YP). Due to disk space limitations, they need to serve from eachother via NFS. At any rate, it would be nice to mount a password file remotely via NFS instead of using YP. However, it seems to me that almost certainly the passwd is necessary to have around at boot time (i.e. I need to log in as root if the server dies). The big question is... is the concept of NFS mounting on a non-empty directory well defined??? Could I place a default passwd file in a directory, and later mount the NFS one on top of it safely.. (would the results be the same between various NFS implementations.... ie.. SUN 4.0, DEC Ultrix, HP UX, Xenix, IBM A/IX) (yes, we have at least one of each). Thanks in advance. Guy
jik@athena.mit.edu (Jonathan I. Kamens) (07/23/89)
In article <2339@orion.cf.uci.edu> Guy Cardwell <gcardwel@envy.eng.uci.edu> writes: >The big question is... is the concept of NFS mounting on a non-empty >directory well defined??? Could I place a default passwd file in a >directory, and later mount the NFS one on top of it safely.. (would >the results be the same between various NFS implementations.... ie.. >SUN 4.0, DEC Ultrix, HP UX, Xenix, IBM A/IX) (yes, we have at least >one of each). Yes, the concept of mounting over a non-empty directory is well-defined, and has been discussed here recently, in reference to having a /tmp or /usr/tmp on the root during boot time, and then mounting something over it via NFS in order to have more space in it during multi-user operation. Our (4.3BSD) man page for mount(2) says the following: >DESCRIPTION > mount attaches a file system to a directory. After a suc- > cessful return, references to directory dir will refer to > the root directory on the newly mounted file system. Dir is > a pointer to a null-terminated string containing a path > name. Dir must exist already, and must be a directory. Its ^^^ > old contents are inaccessible while the file system is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > mounted. ^^^^^^^ Jonathan Kamens USnail: MIT Project Athena 432 S. Rose Blvd. jik@Athena.MIT.EDU Akron, OH 44320 Office: 617-253-4261 Home: 216-869-6432
seth@ctr.columbia.edu (Seth Robertson) (07/24/89)
In article <12921@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: >Yes, the concept of mounting over a non-empty directory is >well-defined >> Its >> old contents are inaccessible while the file system is >> mounted. The concept may be well defined, but the implementation bytes the big one. In SunOS 4.0.3 seth elara> cd /mnt seth elara> ls testfile seth elara> cat testfile This is a test. seth elara> mount leda:/image /mnt seth elara> ls lost+found not found vdo not found seth elara> cd vdo vdo bad directory seth elara> cat testfile This is a test. seth elara> cd / seth elara> cd /mnt seth elara> ls lost_found vdo seth elara> cd vdo seth elara> pwd /mnt/vdo (Note: This is a hand copy of what actually happened, so I may have screwed up a little on the error messages, but this is, for all intents and purposes, what happened) -- -Seth Robertson seth@ctr.columbia.edu
jik@athena.mit.edu (Jonathan I. Kamens) (07/24/89)
In article <1989Jul23.194057.4247@ctr.columbia.edu> seth@ctr.columbia.edu (Seth Robertson) writes: %The concept may be well defined, but the implementation bytes the big one. % %In SunOS 4.0.3 % %seth elara> cd /mnt %seth elara> ls %testfile %seth elara> cat testfile %This is a test. %seth elara> mount leda:/image /mnt %seth elara> ls %lost+found not found %vdo not found %seth elara> cd vdo %vdo bad directory %seth elara> cat testfile %This is a test. %seth elara> cd / %seth elara> cd /mnt %seth elara> ls %lost_found vdo %seth elara> cd vdo %seth elara> pwd %/mnt/vdo % %(Note: This is a hand copy of what actually happened, so I may have %screwed up a little on the error messages, but this is, for all intents %and purposes, what happened) I suspect that the problem is that you were in the directory onto which you tried to mount something when you issued the mount command. You are not supposed to be able to mount something on top of a busy directory, and if a process has a directory open as its cwd, that makes the directory busy. Try cd'ing out of the /mnt directory before doing the mount. That should solve the problem. If I tried to do the same thing here (BSD 4.3), I would get a device busy error and the mount would fail. I do not know why you did not. In fact, here it is: achates# cd /mnt achates# cat testfile This is a test. achates# mount priam:/slush /mnt mount: priam:/slush on /mnt: Device busy mount: giving up on: /mnt Jonathan Kamens USnail: MIT Project Athena 432 S. Rose Blvd. jik@Athena.MIT.EDU Akron, OH 44320 Office: 617-253-4261 Home: 216-869-6432
jeff@quark.WV.TEK.COM (Jeff Beadles) (07/24/89)
>In article <12921@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: >>Yes, the concept of mounting over a non-empty directory is >>well-defined >>> Its >>> old contents are inaccessible while the file system is >>> mounted. In article <1989Jul23.194057.4247@ctr.columbia.edu> seth@ctr.columbia.edu (Seth Robertson) writes: >The concept may be well defined, but the implementation bytes the big one. >In SunOS 4.0.3 >seth elara> cd /mnt >seth elara> ls >testfile >seth elara> cat testfile >This is a test. >seth elara> mount leda:/image /mnt [ Stuff deleted ] I think that your Sun has a fairly serious problem if it allowed you to do this. If the above is what you did, you SHOULD get a 'mount point busy' as you are in /mnt when you mount on top if it. (The same would apply for unmount/umount) This is what happens under Utek (4.2 based BSD, with NFS) Script started on Sun Jul 23 13:54:16 1989 rq:jeff> cd /tmp rq:tmp> mkdir foo rq:tmp> cd foo rq:foo> /etc/mount tango:/ /tmp/foo mount: tango:/ on /tmp/foo: Device busy mount: giving up on: /tmp/foo rq:foo> /etc/mount | egrep tango rq:foo> cd / rq:tmp> rmdir /tmp/foo rq:tmp> ^D script done on Sun Jul 23 13:55:13 1989 -Jeff -- Jeff Beadles Utek Sustaining Engineering, Tektronix Inc. jeff@quark.WV.TEK.COM
bsa@telotech.UUCP (Brandon S. Allbery) (07/29/89)
In article <1989Jul23.194057.4247@ctr.columbia.edu>, seth@ctr (Seth Robertson) writes: +--------------- | In article <12921@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: | >Yes, the concept of mounting over a non-empty directory is | >well-defined | >> Its | >> old contents are inaccessible while the file system is | >> mounted. | | The concept may be well defined, but the implementation bytes the big one. | | In SunOS 4.0.3 | seth elara> cd /mnt | seth elara> ls | testfile | seth elara> cat testfile | This is a test. | seth elara> mount leda:/image /mnt | seth elara> ls | lost+found not found +--------------- This is correct, and happens even for local mounts. The mount(2) system call changes the mapping used to go from a pathname to an inode. In the case of the current directory, the inode is already known, so mount(2) won't affect it; if your current directory is the directory you mounted on, you'll continue to see the same contents after the mount until you explicitly "cd" back to it, at which time the pathname-to-inode mapping will discover that "/mnt" is a different inode. "Fixing" this (I don't consider it a bug, so I don't advocate fixing it) would require replacing u.u_cdir (inode of current directory) with a pathname, and requiring namei() to always start from root and parse the pathname from the ublock first in the case of a relative filename. This would be slow and ugly, IMHO. ++Brandon -- Brandon S. Allbery @ telotech, inc. (I do not speak for telotech. Ever.) *This article may only be redistributed if all articles listed in the header's* * References: field, and all articles listing this one in their References: * * fields, are also redistributed. *
jc@minya.UUCP (John Chambers) (08/04/89)
> Our (4.3BSD) man page for mount(2) says the following: > >DESCRIPTION > > mount attaches a file system to a directory. After a suc- > > cessful return, references to directory dir will refer to > > the root directory on the newly mounted file system. Dir is > > a pointer to a null-terminated string containing a path > > name. Dir must exist already, and must be a directory. Its > ^^^ > > old contents are inaccessible while the file system is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > mounted. > ^^^^^^^ Unfortunately, this isn't quite true. It neglects to mention that any files in the directory that were opened before the mount will stay open and usable by the process(es) until they are closed (or the process(es) die(s)). This may sound like a bit of pickiness, but in fact you can use it to produce an interesting and amusing denial-of-services puzzle to entertain your Unix-wizard friends. What you do is arrange for a program to be started before the mount that creates a file in /tmp, then slowly adds to the file. You can fill up the file system, and the file is invisible to everyone but you. Running du will show that all the directories in the filesystem don't nearly account for all the space, but there's no free space left. This isn't all that marvelous a trick, of course, since you can do the same thing without any mounts, by creating the file, unlinking it, and then filling it up. But it's still pretty good for stumping neophytes who have pretensions to wizardhood. I've seen it happen "innocently", when the file in question was an audit trail produced by some daemon, and a mount was done after the daemon was started. For instance, I've seen the yp directory put into /usr/etc/yp, when /usr/etc was a mounted partition. The yp servers got started before the mount, so they wrote to the "real" /usr/etc/yp, which became hidden when the mount occurred. But with debugging enabled, the daemons slowly added to their hidden audit trails, filled up the /usr partition, and nobody could figure out why it was full. A bit of detective work in single-user mode solved the problem, since the mounts didn't happen then. It also explained why the daemons seemed to be ignoring the command to write their debug output. To paraphrase Stephen Hawking, they did write their output; they just wrote it where it couldn't be seen. (Hmmm...that suggests another interesting cosmological approach: The reason that we can't see the "hidden variables" below the level of the quarks is that a quark is actually a virtual object that is "mounted" over the lower-level structure in the memory of the cosmic computer that is running the simulation that we call "the universe", thus hiding the details from access from above. Ooops; this is unix-wizards, not sci.farout-physics; excuse me! ;-) -- #echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:' echo ' John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)' echo '' saying
mouse@mcgill-vision.UUCP (der Mouse) (08/09/89)
In article <1989Jul28.173335.1815@telotech.uucp>, bsa@telotech.UUCP (Brandon S. Allbery) writes: > In article <1989Jul23.194057.4247@ctr.columbia.edu>, seth@ctr (Seth Robertson) writes: >> In article <12921@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: >>> Yes, the concept of mounting over a non-empty directory is >>> well-defined >>>> Its old contents are inaccessible while the file system is >>>> mounted. >> The concept may be well defined, but the implementation bytes the >> big one. >> In SunOS 4.0.3 >> seth elara> cd /mnt >> seth elara> ls >> testfile >> seth elara> cat testfile >> This is a test. >> seth elara> mount leda:/image /mnt >> seth elara> ls >> lost+found not found > This is correct, and happens even for local mounts. Read more closely. Why is it trying to find lost+found at all? There's no lost+found in the directory being covered by the mount. It seems that when ls is reading . to get the names, it sees the mounted directory, but when it tries to look up the names it found, it gets the mounted-upon directory. > if your current directory is the directory you mounted on, you'll > continue to see the same contents after the mount until [...] Yes, but he isn't, that's the point. It goes schizoid: the it sometimes looks like one and sometimes the other, depending on the operation being performed. > *This article may only be redistributed if all articles listed in the header's* > * References: field, and all articles listing this one in their References: * > * fields, are also redistributed. * You can be certain I'm not going to run around making sure we've got all the referenced articles before shipping yours out with the rest of the news that arrived at about the same time. Is this what you want me to have to do? It's what it sounds like. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu