Correction: Unionfs doesn't make additional copies in the page cache.
Arnd, I favor a more generic approach, one that will work with the vast
majority of file systems that people use w/ unioning, preferably all of
them. Supporting copy-on-write in cramfs will only help a small subset of
users. Yes, it might be simple, but I fear it won't be useful enough to
convince existing users of unioning to switch over. And I don't think we
should add CoW support in every file system -- the complexity will be much
more than using unionfs or some other VFS-based solution.
I can see some advantages (re: cache coherency) by hacking CoW support
directly into a f/s. If you want to use a filesystem-specific solution,
then I suggest you don't modify a file system used as a source in a union,
but one used as a destination. You'll have better overage that way. The
vast majority of times, unionfs users will either write to tmpfs or ext2;
but the source readonly f/s can be a lot of different ones (most popular are
ext*, nfs*, isofs, and cramfs/squashfs).
I find it somewhat ironic to hear the argument that "union mounts isn't
stable yet, so lets come up with a new solution inside cramfs." Why should
your solution become stable much faster than union mounts (which also had
patches floating around for a long time already).
If you have cycles to spare, why not help Bharata and Jan?
Cheers,
Erez.
--
