Date: Mon, 21 Nov 2005 15:41:50 +0100
From: Matthias Andree <matthias.andree@gmx.de>
To: linux-kernel@vger.kernel.org
Subject: Re: what is our answer to ZFS?
Message-ID: <20051121144150.GA10189@merlin.emma.line.org>
Mail-Followup-To: linux-kernel@vger.kernel.org
References: <11b141710511210144h666d2edfi@mail.gmail.com> <20051121095915.83230.qmail@web36406.mail.mud.yahoo.com> <20051121101959.GB13927@wohnheim.fh-wedel.de> <20051121114654.GA25180@merlin.emma.line.org> <1132574831.15938.14.camel@localhost> <20051121131832.GB26068@merlin.emma.line.org> <1132582713.15938.22.camel@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1132582713.15938.22.camel@localhost>
User-Agent: Mutt/1.5.11
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3534
Lines: 77

On Mon, 21 Nov 2005, Kasper Sandberg wrote:

> > If the precondition is "adhere to CodingStyle or you don't get it in",
> > and the CodingStyle has been established for years, I have zero sympathy
> > with the maintainer if he's told "no, you didn't follow that well-known
> > style".
> 
> that was not the question, the question is if the code is in development
> phase or not (being stable or not), where agreed, its their own fault
> for not writing code which matches the kernel in coding style, however
> that doesent make it the least bit more unstable.

As mentioned, a file system cannot possibly be stable right after merge.
Having to change formatting is a sweeping change and certainly is a
barrier across which to look for auditing is all the more difficult.

> > I have had, without hard shutdowns, problems with reiserfs, and
> > occasionally problems that couldn't be fixed easily. I have never had
> > such with ext3 on the same hardware.
> > 
> you wouldnt want to know what ext3 did to me, which reiserfs AND reiser4
> never did

OK, we have diametral experiences, and I'm not asking since I trust you
that I don't want to know, too :) Let's leave it at that.

> > I don't care what its name is. I am aware it is a rewrite, and that is
> > reason to be all the more chary about adopting it early. People believed
> > 3.5 to be stable, too, before someone tried NFS...

> nfs works fine with reiser4. you are judging reiser4 by the problems
> reiserfs had.

Of course I do, same project lead, and probably many of the same
developers. While they may (and probably will) learn from mistakes,
changing style is more difficult - and that resulted in one of the major
non-acceptance reasons reiser4 suffered.

I won't subscribe to reiser4 specific topics before I've tried it, so
I'll quit. Same about ZFS by the way, it'll be fun some day to try on a
machine that it can trash at will, but for production, it will have to
prove itself first. After all, Sun are still fixing ufs and/or logging
bugs in Solaris 8. (And that's good, they still fix things, and it also
shows how long it takes to really get a file system stable.)

> i have had less trouble by using the reiser4 patches before even hans
> considered it stable than i had by using ext3.

Lucky you. I haven't dared try it yet for lack of a test computer to
trash.

> there is quite a big difference between stuff like submount and the
> filesystem itself.. and as you pointed out, reiserfs in the beginning
> was a disappointment, do you seriously think they are willing to take
> the chance again?

I thing naught about what they're going to put at stake. reiserfs 3 was
an utter failure for me. It was raved about, hyped, and the bottom line
was wasted time and a major disappointment.

> > Yup. So the test and fix cycles that were needed for reiserfs 3.5 and
> > 3.6 will start all over. I hope the Namesys guys were to clueful as to
> > run all  their reiserfs 3.X regression tests against 4.X with all
> > plugins and switches, too.
> you will find that reiser4 is actually very very good.

I haven't asked what I'd find, because I'm not searching. And I might
find something else than you did - perhaps because you've picked up all
the good things already when I'll finally go there ;-)

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/