Re: [RFC 0/7] [RFC] cramfs: fake write support

From: Arnd Bergmann
Date: Mon Jun 02 2008 - 03:13:34 EST


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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/