Unioning file systems: Architecture, features, and design choices

Unioning file systems: Architecture, features, and design choices

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

---

(Log in to post comments)