Arnd Bergmann: > Besides, there are a many more problems with unionfs, which have > all been mentioned in the previous review cycles. Aufs doesn't > address those either AFAIK, with the exception of at least > not making additional copies in the page cache when writing to > a file. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
