On Wednesday 08 November 2006 14:04, McKown, John wrote:
>I understand what these do. Can anybody explain to me why I would use
>them? Eg, I could do something like:
>
>mount --rbind /opt/lib/IBM /var/lib/IBM
>
>Now I can get to the same physical files via /opt/lib/IBM or
>/var/lib/IBM. I guess that if I messed something up and could not find
>the config file, this would be helpful. But how is that better than:
>
>ln -s /opt/lib/IBM /var/lib/IBM
>
>??? The best that I can figure out is if I did something like:
>
>mount -bind /bin /tmp/bin
>chroot /tmp /bin/sh
>
>to get to a chroot'ed environment. Is that the reason? Oh, and does it
>work? I haven't tried because I'm not where I can easily get to a Linux
>system right now.
Here's one application of bind-mounts:
Suppose you want to have the Linux system software on some shared DASD, which
must be read-only. You could put /bin, /boot, /lib, /sbin, and perhaps some
other stuff all into one shared filesystem. Now you could make that be the
root filesystem of all your Linux guests, but then / won't be writable and
that's not good. Instead, you mount that shared filesystem somewhere else
(say, /SHARED) and then bind-mount each sub-directory to its correct
location:
/SHARED/bin --> /bin
/SHARED/boot --> /boot
and so on. Now everything is at the correct path.
Why not use symlinks? Well, using the mount table is more efficient because
it is within the kernel, whereas symlinks require file I/O to follow. Also,
if you're doing something like the example above you might need some files to
be on the actual root filesystem before you can mount the shared one. You
might need /bin/mount on the root filesystem, for example. :-) You can then
mount /SHARED/bin on top of /bin and suddenly have all the other /bin/* tools
available. If /bin is a symlink, you can't very well have /bin/mount exist
at boot-time.
My product, which automates the creation and configuration of Linux guests,
uses bind-mounts in this way. I chose to use them because having a longer
mount table is less intrusive than changing the types of a bunch of system
directories. Users see the same directory tree they are used to seeing.
Also, relative paths don't work right across symlinks. If you make /bin
symlink to /SHARED/bin, and a process chdirs to /bin, then ../etc refers
to /SHARED/etc, which might not exist, when what you really want is /etc.
That's not good.
- MacK.
-----
Edmund R. MacKenty
Software Architect
Rocket Software, Inc.
Newton, MA USA
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
