>> I'd actually favour an approach that completely de-specializes things,
>> e.g. by adding a mechanism to allow mounted file system to be moved to
>> other places, including on top of the existing root. Then make it
>> possible to move a file system with another one on top to a different
>> place, or to unmount it. I think there are actually some patches for
>> at least part of such functionality floating around.
>
> That would be nice, but may complicate things unneccesarily. In the
> general case, you may have to worry about garbage-collecting parts of
> the filesystem that are now unreachable, and that would be majorly
> painful.
As long as you can refer to the filesystem in some way, there is no need
to garbage collect. Garbage collection might even be undesirable.
Consider a typical /home filesystem. You have:
1. data about the filesystem itself (driver, device, flags...)
2. mount point ("/home")
3. root ("/")
4. level (this is on top, and "/" is at the bottom)
5. unique mount ID (a kernel memory address would work)
Not even getting into per-user namespaces, it would be nice to be able
to make parts of a filesystem appear in different places.
Example: /dev/hda2 is an old Linux install, and /dev/hdc1 is a new install.
You might like to have /dev/hdc1 be your root filesystem, but also mount
the /home and /usr/local directories of the filesystem on /dev/hda2.
Symlinks are a cruddy way to do this. Loopback directory mounts are a bit
better, but they add overhead and still require that you mount the whole
/dev/hdc1 filesystem in some location. AFAIK, only NFS lets you mount the
same filesystem multiple times below the root.
Now consider two /proc filesystems mounted on the same place. I'm not sure
if this is currently allowed, but it ought to be. There would need to be
a way to refer to each filesystem, and ought to be a way to change which
one is visible on top. This seems to require some kind of mount ID provided
by the kernel.
When /usr and /usr/local are separate filesystems, one must umount them
in a particular order. That is a bit annoying, especially when a buggy
kernel is unable to umount /usr/local. Admins ought to be able to detach
filesystems from the namespace without actually shutting them down.
Think about that. When you do a normal umount, you are really doing two
operations at once. The filesystem is first disconnected from the namespace,
then it is shut down (blocks written, marked clean, etc.). The opposite
happens at mount time. If these operations are made independent, then
admins could make a filesystem appear in 0, 1, or many places while it is
in a running state.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/