linux-kernel - Re: Versioning file system

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: <20070618153238.GG2061@think.oraclecorp.com>
Date:	Mon, 18 Jun 2007 11:32:38 -0400
From:	Chris Mason <chris.mason@...cle.com>
To:	Jörn Engel <joern@...fs.org>,
	alan <alan@...eserver.org>, "H. Peter Anvin" <hpa@...or.com>,
	Jack Stone <jack@...keye.stone.uk.eu.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	akpm@...ux-foundation.org, viro@...iv.linux.org.uk
Subject: Re: Versioning file system

On Mon, Jun 18, 2007 at 03:45:24AM -0600, Andreas Dilger wrote:
> Too bad everyone is spending time on 10 similar-but-slightly-different
> filesystems.  This will likely end up with a bunch of filesystems that
> implement some easy subset of features, but will not get polished for
> users or have a full set of features implemented (e.g. ACL, quota, fsck,
> etc).  While I don't think there is a single answer to every question,
> it does seem that the number of filesystem projects has climbed lately.
> 
> Maybe there should be a BOF at OLS to merge these filesystem projects
> (btrfs, chunkfs, tilefs, logfs, etc) into a single project with multiple
> people working on getting it solid, scalable (parallel readers/writers on
> lots of CPUs), robust (checksums, failure localization), recoverable, etc.
> I thought Val's FS summits were designed to get developers to collaborate,
> but it seems everyone has gone back to their corners to work on their own
> filesystem?

Unfortunately, I can't do OLS this year, but anyone who wants to talk on
these things can drop me a line and we can setup phone calls or whatever
for planning.  Adding polish to any FS is not a one man show, and so I know
I'll need to get more people on board to really finish btrfs off.

One of my long term goals for btrfs is to figure out the features and
layout people are most interested in for filesystems that don't have to
be ext* backwards compatible.  I've got a pretty good start, but I'm
sure parts of it will change if I can get a big enough developer base.

> 
> Working on getting hooks into DM/MD so that the filesystem and RAID layers
> can move beyond "ignorance is bliss" when talking to each other would be
> great.  Not rebuilding empty parts of the fs, limit parity resync to parts
> of the fs that were in the previous transaction, use fs-supplied checksums
> to verify on-disk data is correct, use RAID geometry when doing allocations,
> etc.

Definitely.  There's a lot of work in the DM integration bits that are
not FS specific.

-chris

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