Messages in this thread | | | Date | Sun, 26 Mar 2000 20:27:08 -0500 (EST) | From | Alexander Viro <> | Subject | [Announce][CFT] loopback mounts and stuff |
| |
Folks, there is a cleanup of mount-related stuff underway. Right now the patch seems to be usable for testing. It doesn't include pieces in nfsd and auotfs*, so these simply wont compile, but it should <knocking the wood> work with everything else.
It allows a) to mount the same filesystem several times. Yup, ext2 included. No cache coherency problems - all instances share the dentry tree. b) to work with shmfs without mounting it. c) to do explicit loopback mount. As in # mount -t bind /usr/X11R6 /mnt # ls /mnt bin doc include lib man share # cd /mnt # ls .. bin dev home lost+found mnt proc sbin usr boot etc lib misc opt root tmp var (IOW, unlike the usage of symlinks it gives correct behaviour on ..) d) to mark filesystem type as 'single'. One superblock will be created when you initialize the driver, all later mounts of that type will be aliases to that one. IOW, we can start storing procfs immediately in dcache - just a normal tree. Moreover, kernel can access that tree even if it's not mounted by user. That's how the shmfs stuff is done. Oh, and all instances will share the device number, so you can create a thousand chroot jails, mount devpts on each and spend 1 (one) anonymous device. Ditto for procfs, etc.
Patch (against 2.3.99-pre3) lives on ftp://ftp.math.psu.edu/pub/viro/mount-patch-4.
Folks, give it a try. There may be bugs. I think that it's cleaner than the old code, but don't let it play with critical data. Bug reports are more than welcome, indeed. Another thing that is _very_ welcome is a discussion of the export rules in situation when filesystems on server may be mounted several times (as well as the current implementation - I'ld really like to hear comments on it, in particular on the exp_parent(). It's either buggy and doesn't what it is supposed to do or contains seriously superfluous code). General comments on the patch are also welcome, indeed. Cheers, Al
- 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/
| |