linux-kernel - Re: New filesystem for Linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1LbycM-0007FV-Rg@pomaz-ex.szeredi.hu>
Date:	Tue, 24 Feb 2009 15:50:42 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	hooanon05@...oo.co.jp
CC:	miklos@...redi.hu, tomas@...x.org, akpm@...ux-foundation.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: New filesystem for Linux kernel

On Tue, 24 Feb 2009, hooanon05@...oo.co.j 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/