Unioning file systems: Architecture, features, and design choices
Posted Jan 15, 2013 23:48 UTC (Tue) by nix
In reply to: Unioning file systems: Architecture, features, and design choices
Parent article: Unioning file systems: Architecture, features, and design choices
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
to post comments)