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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1LcH0H-00016K-Im@pomaz-ex.szeredi.hu>
Date:	Wed, 25 Feb 2009 11:28:37 +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 Wed, 25 Feb 2009, hooanon05@...oo.co.j wrote:
> > 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.
> 
> If you really think it is a better way to get merged into mainline, then
> I'll try implement such version.

I'd personally be more motivated to review <2000 line chunks (where
each step adds new functionality and makes sense in itself), than a
20000 line filesystem all in 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.
> 
> It sounds like an ODF (on disk format) version of unionfs (while it
> seems to be inactive).
> At implementing, I don't think it easier to maintain delta of filedata
> and metadata. Since aufs has a writable branch in it, it is better and
> easier to maintain data in a branch fs.

Perhaps it's easier, but copy-up is a very inefficient operation, both
in disk space and in time.  My personal opinion is that a "delta"
filesystem would be cleaner and more useful than a writable union.
Writable union filesystems need many hacks to make them useful, such
as copy-up, whiteouts, inode number tables, virtual hard links, etc.

But that's just a thought, I haven't gone too deeply into this.

> If you think there should not be any writable branch in aufs, and all
> "write" goes to a new filesystem format, then it is equivalent to a
> writable branch, isn't it?

Yes, it should be equivalent.

> If you say "just a part of write" goes to a new fs, then I don't think
> we can support several essential features, for instance mmap.

It should be possible to support mmap.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ