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.
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 <><
--
