Re: New filesystem for Linux kernel

[Miklos Szeredi]

On Tue, 24 Feb 2009, hooanon05@xxxxxxxxxx wrote:
> I have to admit aufs is big, but actually, as I wrote in the documents,
> aufs2 has already dropped several features. And I believe it is the core
> feature set. If aufs2 drops some more features, then both of users and
> reviewers will say it doesn't work in this case, in that case. I don't
> think you would like to review such unusable code in real world.

It's always easier to review something with less features, even if
that feature set is too little for real world use.

Maybe it has all got to get into mainline to be really useful, but
still, splitting it up by functionality (not just files) helps
reviewers a lot.

Let's see this feature list:

> 1. Features
> ----------------------------------------
> - unite several directories into a single virtual filesystem. The member
>   directory is called as a branch.

Sounds like a core functionality :)

> - you can specify the permission flags to the branch, which are 'readonly',
>   'readwrite' and 'whiteout-able.'

The simplest version is with all branches read-only.  That gets rid of
a _huge_ amount of complexity, yet it's still useful in some
situations.  It also deals with a lot of the basic infrastucture
needed for stacking.

> - by upper writable branch, internal copyup and whiteout, files/dirs on
>   readonly branch are modifiable logically.

Right.  The second most simple version is all branches read-only except the
top one.

And that's when one starts thinking about whether unioning is really
the right solution.  Instead this could be implemented with a special
filesystem format that only contains deltas to the data, metatata and
directory tree.  It would be much more space efficient, could easily
handle renames, hard links etc, without all the hacks that
unionfs/aufs does.

Has this been discussed somewhere?

Thanks,
Miklos
--
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/