| |||||||||||||
Unioning file systems: Architecture, features, and design choicesUnioning file systems: Architecture, features, and design choicesPosted Jan 15, 2013 15:15 UTC (Tue) by anselm (subscriber, #2796)In reply to: Unioning file systems: Architecture, features, and design choices by nix Parent article: Unioning file systems: Architecture, features, and design choices
That's why I said »assumption«, not »guarantee«. It is clear that it is possible to stipulate cases where if you remove a file, another one will immediately pop up in its place – and it is also clear that one shouldn't write programs based on the idea that just because a file was removed just now, another one of the same name cannot have appeared in the meantime. However, if – like most of the people most of the time – you're just working away in your shell somewhere below $HOME, that sort of thing is highly unlikely. In that context, chances are that if you just removed a file you'd expect it to be gone, not replaced by some older or default version. For example, I often do something like »rm *~« in order to clean up before, e.g., making a tar file, and I don't want this to unearth random files from the layer below. The other problem is that with this approach it is impossible to make files go away completely if they exist in a read-only layer. This can be a hassle for programs that assume certain defaults if they don't have a certain configuration file. If somebody in your virtualisation base image helpfully supplied a configuration file you don't want, either you're in luck because the program doesn't mind an empty configuration file that you put on top, or else you will have to come up with one that undoes just the stuff you don't want because you can't get rid of the unwanted file altogether.
(Log in to post comments)
Unioning file systems: Architecture, features, and design choices Posted Jan 15, 2013 22:22 UTC (Tue) by hummassa (subscriber, #307) [Link]
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] 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...
Unioning file systems: Architecture, features, and design choices Posted Jan 15, 2013 23:48 UTC (Tue) by nix (subscriber, #2304) [Link] That's why I said »assumption«, not »guarantee«.Sorry, I tend to read 'assumption of X' as a statement that we had better have a guarantee of X, lest we break the code making that assumption. Miscommunication. :) However, if – like most of the people most of the time – you're just working away in your shell somewhere below $HOME, that sort of thing is highly unlikely.Quite. It could perfectly well confuse the heck out of users, and I don't see a way to implement the less-confusing whiteout model using this sort of symlink-path. It just shouldn't break any software that isn't already broken. The other problem is that with this approach it is impossible to make files go away completely if they exist in a read-only layer.Yeah -- but, again, it's impossible to make files go away completely (or change in any way) if they exist on a read-only filesystem, and nobody complains about that. I personally don't see this sort of symlink-path model as a viable way to implement union mounts, but they could be interesting in and of themselves regardless. It's worth thinking about -- the sort of experimentation that doesn't happen often in Linux anymore due to the drag of the installed base of software and its tedious demands that we not gratuitously break it :P
Unioning file systems: Architecture, features, and design choices Posted Jan 16, 2013 0:06 UTC (Wed) by anselm (subscriber, #2796) [Link] Yeah -- but, again, it's impossible to make files go away completely (or change in any way) if they exist on a read-only filesystem, and nobody complains about that. That's because read-only filesystems don't pretend to be read-write filesystems.
|
|||||||||||||