On Sun, Jul 22, 2012 at 9:56 PM, James Davidson <[email protected]> wrote: > So, is development for unionfs basically over and overlayfs is the way > forward?
No idea, really. I understand that Ubuntu live CDs use overlayfs, though. Personally, I tried overlayfs with good results so far: 1. It allows finer [no]exec and [no]suid granularity, since these file capabilities are affected by respective lowerdir / upperdir mount attributes (at overlayfs mount time, later changes are ignored). So, for instance, you can have SquashFS /etc branch mounted with "exec" attribute, and tmpfs upperdir mounted with "noexec". If someone changes an init.d service executable (perhaps maliciously), it cannot be executed afterwards. "nodev", however, is handled by overlayfs, and corresponding lowerdir / upperdir options are ignored. 2. Better ACL support: ACL changes work even when an inode is not present in upper layer (similarly to chmod) — this did not work in Unionfs the last time I tried. 3. Better filesystem integration: whiteouts and opaque dirs are indicated by “trusted.overlay.*” symlink xattrs in rw tmpfs layer. Drawbacks so far: 4. No file-level inotify support (whereas directory-level events work) — https://bugs.launchpad.net/bugs/882147, https://lkml.org/lkml/2012/2/28/223. The filesystem advertises inotify support, however (it works for directories, after all), so tail -f does not work, for example (even if the file already exists in the upper layer). Depending on your use cases, this might be a serious problem, since some aplpications use inotify for watching for configuration changes (e.g., NetworkManager — from Launchpad bug, or PolKit). 5. Only two branches are supported, and upper branch must support xattrs. Lower branch can be anything, however, so overlayfs filesystems can be stacked. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte _______________________________________________ unionfs mailing list: http://unionfs.filesystems.org/ [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
