Dan McGee schrieb:
What one is most likely to land in the kernel? I assume one of these has to be on track to actually get in, and we should go with that and be done with this mess.
unionfs has been in -mm for ages, and aufs2 has just been submitted for mainline inclusion a few weeks ago.
Why is it that everyone seems to use union filesystems, and yet none of them have matured enough to get in the tree?
When unionfs was first submitted, apart from coding style and implementation issues, it had design problems, like non-consistent inode numbers in some cases (which aufs2 solves, according to the author). Also, it seems that people weren't happy about the general approach: Rather than stacking filesystems, doing copyup and such, it was suggested that a special filesystem should be designed that has its own on-disk-format for storing differences between an underlying filesystem and the actually visible filesystem. unionfs-odf does this, but apparently it is not very mature. For reference, here are the recent LKML discussions (most of the information from above is from what I read here some time ago and remembered): 23. Feb: aufs design and first comments http://permalink.gmane.org/gmane.linux.file-systems/29813 9. Mar: aufs source http://permalink.gmane.org/gmane.linux.file-systems/30026 16. Mar: aufs source, second try http://permalink.gmane.org/gmane.linux.file-systems/30160 This is a lot to read and I have no idea if and when this might be included. However, we should be able to build this as an external module with only a non-intrusive patch to the kernel (it exports some symbols that are otherwise not exported), while I don't know how intrusive unionfs is.