Mount on top of / ??

Benjamin Scott dragonhawk at iname.com
Thu Mar 31 21:12:00 EST 2005


On Thu, 31 Mar 2005, Paul Lussier wrote:
>> 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.

    I don't think "file handle" is the proper term here; I believe "mount point" 
would be.  I believe "file handle" refers to the opaque data type (i.e., C 
data structure) used in the kernel to track open files.  If my usage is 
correct, a single file handle could never refer to more then one thing at a 
time.

>  To issue a command of 'umount /' is going to confuse the kernel.

    Normally, unmounting a filesystem that's been mounted "on top" of another 
filesystem works fine, and unmounts the filesystem that is "on top".  The 
kernel is not confused, just the operator.  :)

  	# mount -o loop -r FC3-i386-disc1.iso /mnt/tmp
  	# mount -o loop -r FC3-i386-disc2.iso /mnt/tmp
  	# umount /mnt/tmp
  	# umount /mnt/tmp
  	# umount /mnt/tmp
  	umount: /mnt/tmp: not mounted

> 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.

    Well, for starters, it won't work if what you mounted on / isn't a complete 
Unix file system tree.  You need the special files in /dev/, the commands in 
/sbin/, and the libraries in /lib/, and maybe /etc/mtab/ as well.  Since most 
of the time we can expect this situation to arise only in the case of operator 
error, chances are you're going to be hosed.  :-)

    I'm also not sure it would work even then.  Normally, on a Linux system, the 
root directory is *always* open, once by every process.  Now, the file handles 
already opened before the mount will still refer to the "original" root 
filesystem, since the kernel tracks open inodes independent of their name. 
But I suspect the system will immediately end up opening file handles on the 
"new" root, which would then make it impossible to close.

> 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 :)

    *Exactly*.  :-)

> "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!"

    Like I said above, processes that already have the "old" / open will be 
unaffected, because once a file is open, the name used to open the file is no 
longer used.

    In particular, one aspect of nix file semantics that catches many by 
surprise when they first encounter it is that one can unlink ("delete" or 
"remove") a file while it is open.  The following is legal:

  	fd = open("/tmp/foo", O_CREAT);
  	unlink("/tmp/foo");
  	write(fd, "123456789", 10);

    The first line opens a file (called "/tmp/foo"), creating it if needed. 
The second line unlinks the file, removing all reference to it from the 
directory tree.  However, the "file" itself -- the inode -- still exists, and, 
since it is still open, will not be freed by the kernel.  You can still do I/O 
on it all day long, until such time all the file descriptors referring to said 
inode are closed.  At that point, the kernel frees the inode and any 
associated disk storage.

    This is often done deliberately with temporary files, so that a program 
doesn't have to worry about cleaning up said files when finished. 
Programmers may notice a similarity between this and runtime environments that 
do "automatic garbage collection".

    (I expect Paul knows this and just forgot, but I imagine others might not.)

>  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?

    Both, of course!  Mmmmmm, beer.  ;-)

-- 
Ben <dragonhawk at iname.com>



More information about the gnhlug-discuss mailing list