Unioning file systems: Architecture, features, and design choices

Posted Jan 15, 2013 22:22 UTC (Tue) by hummassa (subscriber, #307)
In reply to: Unioning file systems: Architecture, features, and design choices by anselm
Parent article: Unioning file systems: Architecture, features, and design choices

Why would you mount an unionfs over your /home/x?

What you really want to do is to union mount /etc, /usr/share and other places where you want to have writable configuration or data files shadowing read-only (original) files.

In that case, the semantics you Need from -- for instance -- "rm /etc/resolv.conf" is exactly "substitute /etc/resolv.conf for the default file".

Unioning file systems: Architecture, features, and design choices

Posted Jan 15, 2013 22:31 UTC (Tue) by anselm (subscriber, #2796) [Link] (1 responses)

In that case, the semantics you Need from -- for instance -- "rm /etc/resolv.conf" is exactly "substitute /etc/resolv.conf for the default file".

That's not the greatest example – not having an /etc/resolv.conf file at all also means something, and with the »path in symlink« approach you can't make a file that is present in a lower layer appear as if it wasn't there after all, which is something that union filesystems can usually handle.

Unioning file systems: Architecture, features, and design choices

Posted Jan 16, 2013 0:00 UTC (Wed) by hummassa (subscriber, #307) [Link]

You can have "negative filesystem skeletons" like you have in some unionfs implementations. That way, you do "/x -> /a:-/b:/c:-/d" and if you remove a file in /x, the implementation will touch the same name (modulo an extension or prefix) under /b, that will mark said file as inexistent even if it exists in /c...