[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060731192902.GS31121@lug-owl.de>
Date: Mon, 31 Jul 2006 21:29:03 +0200
From: Jan-Benedict Glaw <jbglaw@...-owl.de>
To: Clay Barnes <clay.barnes@...il.com>
Cc: Rudy Zijlstra <rudy@...ons.demon.nl>,
Adrian Ulrich <reiser4@...nkenlights.ch>,
vonbrand@....utfsm.cl, ipso@...ppymail.ca, reiser@...esys.com,
lkml@...productions.com, jeff@...zik.org, tytso@....edu,
linux-kernel@...r.kernel.org, reiserfs-list@...esys.com
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
On Mon, 2006-07-31 12:17:12 -0700, Clay Barnes <clay.barnes@...il.com> wrote:
> On 20:43 Mon 31 Jul , Jan-Benedict Glaw wrote:
> > On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree <matthias.andree@....de> wrote:
> > > Jan-Benedict Glaw schrieb am 2006-07-31:
[Crippled DMA writes]
> > > Massive hardware problems don't count. ext2/ext3 doesn't look much better in
> > > such cases. I had a machine with RAM gone bad (no ECC - I wonder what
> >
> > They do! Very much, actually. These happen In Real Life, so I have to
>
> I think what he meant was that it is unfair to blame reiser3 for data
> loss in a massive failure situation as a case example by itself. What
Crippling a few KB of metadata in the ext{2,3} case probably wouldn't
fobar the filesystem...
> failure robustness counts... " This of course assumes you actually had
> the *exact* same problem with hardware under ext3, pretty much in every
> detail. Of course, so many subtleties interact in massive ways with
The point is that it's quite hard to really fuck up ext{2,3} with only
some KB being written while it seems (due to the
fragile^Wsophisticated on-disk data structures) that it's just easy to
kill a reiser3 filesystem.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@...-owl.de +49-172-7608481
Signature of: Zensur im Internet? Nein danke!
the second :
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists