| |||||||||||||
Unioning file systems: Architecture, features, and design choicesUnioning file systems: Architecture, features, and design choicesPosted 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".
(Log in to post comments)
Unioning file systems: Architecture, features, and design choices Posted Jan 15, 2013 22:31 UTC (Tue) by anselm (subscriber, #2796) [Link] 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...
|
|||||||||||||