Messages in this thread | | | Date | Tue, 15 Jun 1999 03:45:02 -0400 (EDT) | From | "Albert D. Cahalan" <> | Subject | Re: initrd redesign (was Re: Partition nightmare Was: Migrating to |
| |
H. Peter Anvin writes: > Werner Almesberger wrote:
>> 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/
| |