Message-ID: <Pine.LNX.4.64.0706180907580.22137@blackbox.fnordora.org>
Date:	Mon, 18 Jun 2007 09:16:30 -0700 (PDT)
From:	alan <alan@...eserver.org>
To:	Theodore Tso <tytso@....edu>
cc:	Jörn Engel <joern@...fs.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, 18 Jun 2007, Theodore Tso wrote:

> 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.
>
> I view some of the attempts for "from scratch" filesystems as ways of
> testing out various designs as "proof-of-concepts".  It's a great way
> of demo'ing ones ideas, to see how well they work.  There is a huge
> chasm between a proof-of-concept and a full production filesystem that
> has great repair/recovery tools, etc.  That's why it's so important to
> do the POC implementation first, so folks can see how well it works
> before investing a huge amount of effort to make it be
> production-ready.
>

I just wish that people would learn from the mistakes of others.  The 
MacOS is a prime example of why you do not want to use a forked 
filesystem, yet some people still seem to think it is a good idea. 
(Forked filesystems tend to be fragile and do not play well with 
non-forked filesystems.)

> So I actually think the number of these new filesystem proposals are
> *good* things.  It means people are interested in creating new
> filesystems, and that's all good.  Eventually, we'll need to decide
> which design ideas should be combined, and that may be a little tough
> to the egos involved, but that's all part of the darwinian kernel
> programming model.  Not all implementations make it into the kernel
> mainline.  That doesn't mean that the work that was done on the
> various schedular proposals were useless; they just helped demonstrate
> concepts and advanced the debate.

I would like to see more clarification from the designers as to what 
problem they are trying to solve.  Some of the goals seem to be laudable, 
but some are not problems that I worry about.

I see filesystems that are trying to handle the flakeyness of hardware. 
That is useful to me.  I also see people who are trying to archive every 
little change for "legal reasons".  I have a hard time with this one 
because I have a hard enough time keeping spare hard drive space for the 
stuff I want, not the space that someone else wants me to keep.

What I really want are high throughput systems where I can write and read 
as fast as the hardware will allow.  (And then I want faster hardware.)

-- 
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
                                   - Alan Cox
-
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