Kernel Summit 2006: The VFS layer

2006 Kernel Summit coverage on LWN.net.

The session on the virtual filesystem layer was run by Christoph Hellwig and Suparna Bhattacharya. It was an unstructured session which mostly reviewed the list of features that users would like to have. As Christoph noted, the amount of change in the VFS has been relatively small in recent years, an encouraging indication that the code has become reasonably mature. That doesn't stop people from asking for more features, however.

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.

• Next: Scalability.

Index entries for this article
Kernel	Filesystems/Virtual filesystem layer

---

to post comments

unionfs

Posted Jul 19, 2006 22:10 UTC (Wed) by gvegidy (guest, #5063) [Link] (2 responses)

Whats wrong about 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.

unionfs

Posted Jul 20, 2006 1:40 UTC (Thu) by BlueLightning (subscriber, #38978) [Link] (1 responses)

Indeed. I was reading that and thinking "huh? hasn't the work been done already?"

unionfs

Posted Jul 20, 2006 13:08 UTC (Thu) by k8to (guest, #15413) [Link]

I am using it at the moment, and have been for around a year now.

It is solid, if a bit large.

Kernel Summit 2006: The VFS layer

Posted Jul 20, 2006 13:41 UTC (Thu) by dave0 (guest, #32760) [Link]

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/mapfs

I think the Levanta people still use this on their production boxes, but the latest download available from sourceforge seems a bit old.

Kernel Summit 2006: The VFS layer

Posted Jul 20, 2006 16:45 UTC (Thu) by pj (subscriber, #4506) [Link]

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).