On Monday 02 June 2008, Erez Zadok wrote: > Correction: Unionfs doesn't make additional copies in the page cache. Ok, I must have misunderstood something there. Sorry about that. > 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. My idea was to have it in cramfs, squashfs and iso9660 at most, I agree that doing it in even a single writable file system would add far too much complexity. I did not mean to start a fundamental discussion about how to do it the right way, just noticed that there are half a dozen implementations that have been around for years without getting close to inclusion in the mainline kernel, while a much simpler approach gives you sane semantics for a subset of users. > 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). Yes, that absolutely makes sense. I don't care much about a persistant storage for the overlay, so tmpfs (if not ramfs) should be the only place to do it in. It does introduce some of the same old problems though, because you could still write to a bind mounted copy of the underlying file system (unlike cramfs, which is guaranteed to be read-only), which forces you to either to a full copy-up, or can result in inconsistent file contents. Also, stacking multiple union-tmpfs copies on top of each other would be hard to do without the potential to overflow the kernel stack. I'll probably try implementing a '-o union' option tmpfs anyway, just to see how hard it is and what the problems are. > 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). Because the patches are not trying to solve any of the hard problems at all: Persistent storage of overlays, readdir traversal through more than two layers, stable inode numbers, opening a file through two different overlays, copyup, and so on. I'm sure you know more about these problems that I do, but as long as I don't have to care about them, I don't see a problem with my patches (other than the bugs I already described). > If you have cycles to spare, why not help Bharata and Jan? I spent a lot of time on discussing the initial implementation with Jan years ago, and will keep reviewing their patches, but I have neither the time nor the brains to really contribute much to them. As you mentioned in your reply to Jan E., it's on an entirely different scale than doing a small hack to cramfs or tmpfs. Arnd <>< -- 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
