In message <200806020912.49721.arnd@arndb.de>, Arnd Bergmann writes:
[...]
Re: feature creep. Unionfs had more features initially, but we removed
those that users didn't seem to want/use. The bottom line, we've been
maintaining unionfs publicly for 5+ years now, so the set of features we
have is based exactly on what users want. If anyone can give the users what
they want/need in a different, more elegant way, that's great; if not, users
just won't switch to another solution.
That's not an issue when using vm_ops->fault for data.
There is still an issue wrt dentries and topology changes, as Al mentioned
here before. Al suggested to me (at OLS 08) that the superblock struct
might need the same writers-count as has been done for vfsmounts recently;
then you can prevent topology changes during union'ed operations
(esp. copyup).
Yes, but I don't think it's much more than any other layered solution will
have (including ecryptfs and union mounts). This is a general problem in
stackable file systems. Union Mounts, being in the VFS, has the chance to
use less memory indeed, but at a possible cost of increased VFS complexity.
Agreed. We have a different version of unionfs, called unionfs-odf, which
moves the whiteouts and all unioning-related meta-data to a separate, small
persistent partition.
But the better long-term solution is to get WH support in every native f/s.
These patches had been floating around for a while now, and they seem simple
enough that I don't see why it had taken so long to get basic WH support
into mainline (or at least -mm). (Bharata, can you ask akpm to add just the
WH support into -mm perhaps?)
Yes. That's a general problem with stackable file systems. Each layer you
add increases the depth of the stack. There are all already known paths
(involving xfs/nfs/dm, etc.) which overrun the stack and the solution I've
heard was "don't do it." That seems silly to me. Instead, the kernel stack
should be growable dynamically, at the cost of performance.
However, the vast majority of unioning users use just one layer, so even for
us, blowing up the stack has been a rather rare user complaint. And we've
been very mindful of stack usage (i.e., checking and optimizing based on
checkstack.pl).
I agree that it does complicate the implementation, but again, this is
something that _some_ users really want: they want to merge multiple
"packages" together, and ensure that modifications to files/dirs of a given
package stay in their logical location.
I disagree with you that it's confusing to the user. I've never had
complaints that people didn't how to change the branch configurations
dynamically. Heck, people come up with creative ways of using dynamic
branch configurations in all sorts of funky environments that make even my
head spin :-) -- chroot, pivot_root, nfs exports, etc.
Erez.
--
