This is a case where the tool does one thing (mounts a filesystem) and
does its well. If its not encumbered with a lot of safety shields and
anti-pollution devices it is more easily understood, maintained and
generally remains more 'elegant.'
Simple tools can often be used in ways not imagined by the designer and that's not always a bad thing. Who among us has not used a hammer or screwdiver in ways that they were not specifically designed for? Sometimes the results are desirable, sometimes not.
Paul Lussier wrote:
Bill Sconce <[EMAIL PROTECTED]> writes:
Here's a strange question, something (I hope) you've never thought
of doing. A student asked me about it, and I said it's illegal.
But I was wrong...
Yup, you are, and I've mounted file systems on top of other file systems plenty of times, including root. Sometimes intentionally, others not so much :)
What should happen (or what does happen) if you, as root,
# mount -t ext3 /dev/hda9 /
assuming, of course, that the partition /dev/hda9 exists and is
correctly formatted as an ext3 filesystem?
What *should* happen is exactly what *does* happen. /dev/hda9 ends up being the file system mounted at /.
In all three cases the system executes the command and fails to
complain.
Why should it? What you told it to do is perfectly valid, and, as is traditional with most UNIX commands, there is no output if the command succeeds. Check the status of $? from the shell after you execute that command, it's probably 0, indicating the command succeeded.
(I'm not saying that the system is still usable afterwards, only that the command doesn't cause an error message.)
That's because there was no error. You issued a command to the shell, which passed it along to the kernel, which executed your wishes, and it succeeded. Why would you expect there to be an error upon success?
It's not easy to undo, either - trying "umount" generates "device is
busy".
Well, of course it is, you now have *2* file systems mounted on the same file handle. To issue a command of 'umount /' is going to confuse the kernel. Which file handle are you asking for, the first or the second. Rather, try 'umount /dev/hda9'. I don't know if that will work, but I would expect it to, unless of course, you've done something which would keep that file handle open, like cd'ing into it.
I wouldn't be surprised if it didn't work either, you're playing with fire here, and, as such, it's not uncommon to get burned :)
I don't know how to explain what's happening, either to my
student or to myself.
What do you mean? You mounted a second file system on top of a mountpoint (i.e. file handle) which was already in use by another file system. You're now trying to unmount the *file handle*, which points to *two different* file systems. It's like you walking up a table at Martha's after just purchasing a pint of Stout and a pint of Porter, and me saying, "Hey, can I have that beer please?" Am I referring to the Stout, the Porter, or Both?
Common sense dictates that you ask to which I'm referring and for me to clarify myself. However, the OS knows nothing about common sense and, possibly how you, too, should interpret my request, automatically assumes I want both. Well, the obvious answer here from you should be, 'No.' :) In the case of the OS, it's going to look at / and say, "Wait a minute, I've got all these processes, not the least of which is PID 1 (init), that are using /. I can't unmount that *now* you moron!"
What do you think?
Is mounting on / illegal?
Sure, if you couldn't mount on /, you couldn't mount on /.
Should it be?
Err, yes, see above...
If it's legal is there a realistic use case?
Yes, every time you boot, the OS mounts a file system on /.
I think, rather, what you *mean* to ask, is: "Should it be legal to mount 2 file systems on the same mount point?". You might get even more specific and limit this question to just the / mount point, but then you get in to having to write more specific error-handling code for edge-cases. Since it's a lot easier to write code for the general case, then, why not just say what's acceptable for one should be acceptable for all, including /?
There are probably plenty of use cases for mounting multiple file systems on the same mount point. For instance, suppose you have a mangled root file system, or even a read-only file system which prevents you from doing something you normally don't want to do (perhaps it's a security mechanism to limit the ability of someone who's cracked your system). On this one occasion, you need to do something which is currently not possible. But, by mounting another file system over that one, you now can, all without re-booting the system. When you're done, you're now able to unmount the second file system and return the system to the state it was before.
This is probably far more useful if the file system in question is *not* root, but, as I stated before, it's easier to do the same for all rather than consider all the edge cases.
Hmm, actually, a legitmate use case just came to mind, though, it does't involve root (but, since root is "just another file system :).
I often mount and unmount differnt file systems to /mnt all the time. Many times I'll have a CD mounted there. Many times, when creating .iso images, I'll want to mount the image before burning it. Even though I may have something already mounted on /mnt, I'll mount that image right over the existing file system mounted at /mnt to make sure it works correctly, or contains the right data. When I'm done, I'll unmount that image, and still be able access whatever was there before.
Sure, I could create various mount points under /mnt and mount things in different places, but then I waste time a) checking to see what mount points are there, and b) typing more than I need to. Why waste time, when I can just mount something over something else that I don't care about at that single moment in time? And, it's a lot more natural, for me anyway, to just type 'mount foo /mnt' than it is to type 'mount foo /mnt/foo'
_______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
