Kernel Summit 2006: The VFS layer
2006 Kernel Summit coverage on LWN.net. |
There is, it seems, an increasing need to move filesystem attributes from the superblock structure into the vfsmount structure. Some of the work which has been done for NFS, along with the increased interest in filesystem namespaces, makes it more likely that filesystems will be mounted in multiple places, possibly with different attributes.
Better support for user mounts - allowing unprivileged users to mount filesystems - would be nice. Preferably this could be done without requiring that the mount utility be installed setuid root, and without setting things up in advance in the /etc/fstab file. How that can be made to work in a secure way is yet to be worked out, however.
Forced unmounts - unmounting a filesystem regardless of any open references to it - is another wishlist item. This, too, is a hard problem. It is somewhat tied to the request for a revoke() call, which would detach a process from a file it (formerly) had open. It's all solvable, but making it robust will take some work.
The "unionfs" idea - mounting multiple filesystems together and seeing the sum of the files and directories in all of them - is an ongoing request. It looks like too much work, however, for a feature which would get little use. So unionfs is not likely to happen anytime soon. The simpler "union mount" idea, where only the top-level directories are merged, is still a possibility, however.
Ted Ts'o talked briefly about the plans for ext4. He asked if there were any objections to the stated development plan, where a new "ext3dev" filesystem type would be created to receive new features. None were expressed. He did note that doing things this way will have the effect of blocking certain kinds of fixes from getting into ext3. Any fixes which might cause changes in the on-disk format will have to be reserved for ext3dev/ext4 only.
Index entries for this article | |
---|---|
Kernel | Filesystems/Virtual filesystem layer |
Posted Jul 19, 2006 22:10 UTC (Wed)
by gvegidy (guest, #5063)
[Link] (2 responses)
Posted Jul 20, 2006 1:40 UTC (Thu)
by BlueLightning (subscriber, #38978)
[Link] (1 responses)
Posted Jul 20, 2006 13:08 UTC (Thu)
by k8to (guest, #15413)
[Link]
It is solid, if a bit large.
Posted Jul 20, 2006 13:41 UTC (Thu)
by dave0 (guest, #32760)
[Link]
I think the Levanta people still use this on their production boxes, but the latest download available from sourceforge seems a bit old.
Posted Jul 20, 2006 16:45 UTC (Thu)
by pj (subscriber, #4506)
[Link]
Whats wrong about unionfs unionfs
(http://www.fsl.cs.sunysb.edu/project-unionfs.html) and merging it some
time in the future? It looks like they are doing the work neccessary and
there are enough users (especially live cd based distributions) to justify
it.
Indeed. I was reading that and thinking "huh? hasn't the work been done already?"unionfs
I am using it at the moment, and have been for around a year now.unionfs
Another option for union filesystems is mapfs, which worked reasonably well last time I tried it. See http://www.levanta.com/mapfs/index.shtml and http://sourceforge.net/projects/mapfsKernel Summit 2006: The VFS layer
unionfs isn't that much work anyway; I seem to recall it took me about 2 days to write one using an early version of FUSE - the main problem is deciding where/how to store whiteouts (markers that indicate that the file on the 'bottom' layer has been deleted).Kernel Summit 2006: The VFS layer