On Sunday 01 June 2008, Jamie Lokier wrote: > Ok, so why not fix that in unionfs? An option so that holes in the > overlay file let through data from the underlying file sounds like it > would be generally useful, and quite easy to implement. I can imagine a lot of unexpected effects with that. Think of e.g. someone replacing the underlying file with a new one. Then enlarge the file using truncate() and read from it -- suddenly you see the old contents instead of zeroes. Probably fixable as well, but certainly not in a nice way. 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. The real solution of course are VFS based union mounts (think 'mount --union -t tmpfs none /'), but the patches for that are not stable enough for inclusion in mainline yet. > If not unionfs, a "union-tmpfs" combination would be good. Many > filesystems aren't well suited to being the overlay filesystem - > adding to the implementation's complexity - but a modified tmpfs could > be very well suited. Yes, that is similar to one of my earlier ideas as well. Christoph managed to convince me that it's not as easy as I thought, though I can't remember the exact arguments any more. I'll try to think about that some more. One of the problems is certainly the complexity involved in tmpfs to start with, which is the reason I based the code on ramfs instead. 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
