On Monday 02 June 2008, hooanon05@xxxxxxxxxxx wrote: > While I don't have particular objection to your idea and approach to > cramfs, I'd point out that modern LiveCDs tend to save their > modifications to disk. Sure, and I wasn't trying to address those of course. I have a rather specific setup in mind myself, and I figured the same would be useful for others as well, while we are waiting for a generic union mount implementation in the mainline kernel. > And AUFS did address all known problems. If there left something, please > let me know. Ok, I'm sorry for not having looked at it myself. I saw an older version and assumed it was not going to improve much. I'll have another look when I find the time. Unionfs was suffering from severe feature creep (multiple writable branches, runtime branch modification), and aufs seemed to add even more features instead of removing them. Without reading either again, the top problems in unionfs at the time were: * data inconsistency problems when simultaneously accessing the underlying fs and the union. * duplication of dentry and inode data structures in the union wastes memory and cpu cycles. * whiteouts are in the same namespace as regular files, so conflicts are possible. * mounting a large number of aufs on top of each other eventually overflows the kernel stack, e.g. in readdir. * allowing multiple writable branches (instead of just stacking one rw copy on a number of ro file systems) is confusing to the user and complicates the implementation a lot. With the exception of the last two, I assumed that these were all unfixable with a file system based approach (including the hypothetical union-tmpfs). If you have addressed them, how? 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
