I agree w/ Jan E.
Folks, I've said it before: unioning is a deceptively simple idea in
principle, and &^@%*$&^@ hard in practice. And anyone who thinks otherwise
is welcome to write a *versatile* unioning implementation on their own. Once
you get through all corner cases and satisfy all the features which users
want, you have a complex large file system.
I believe that implementing unioning inside actual filesystems is totally the
wrong direction: going to lower layers is wrong, instead of going up to a
VFS-based solution. Unioning is a namespace operation that should not be
done deep inside a lower f/s.
People often wonder why FScache is (reportedly) so complex and big. It's
b/c in some part it has to deal with similar issues: unioning is
copy-on-write, whereas caching is copy-on-read.
Nevertheless, I can understand if the embedded community wants lightweight
unioning. Union Mounts initially may not support everything that unionfs
does, but it should be smaller, and it should be enough I believe for the
basic unioning uses --- perhaps even for the embedded community. If so,
then I suggest people offer to help Bharata and Jan Blunk's efforts, rather
than [sic] cramming unioning into a single file system.
Erez.
--
