linux-kernel - Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

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: <20060731191712.GE17206@HAL_5000D.tc.ph.cox.net>
Date:	Mon, 31 Jul 2006 12:17:12 -0700
From:	Clay Barnes <clay.barnes@...il.com>
To:	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 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:
> > >   * reiser3: A HDD containing a reiser3 filesystem was tried to be
> > >     booted on a machine that fucked up DMA writes. Fortunately, it
> > >     crashed really soon (right after going for read-write.)  After
> > >     rebooting the HDD on a sane PeeCee, it refused to boot. Starting
> > >     off some rescue system showed an _empty_ root filesystem.
> > 
> > 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
> pay attention to them. Once you're in setups with > 10000 machines,
> everything counts. At some certain point, you can even use HDD's
> temperature sensors in old machines to diagnose dead fans.

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
would be more appropriate (and fair) is saying something along the lines
of "in a machine with DMA failure, reiser3 hosed a drive, while ext3
only lost x data (or nothing).  In my situation, every bit of massive
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
filesystems and hardware problems, so we have to keep in mind how much
difference that can make (all the difference in the world), and that,
really, without a statistically significant sample size and some real
analysis, hardware failure comparisons are impossible to do fairly.

Of course, if ext3 were proven to be more robust against failures, I bet
the reiser team would be very interested in all the forensic data you
can offer, since, from what I've seen, they are always trying to make
reiser as good as possible---in speed, flexability, *and* robustness.
If they didn't care about the last, they'd benifit greatly from not
journaling!  :-P

--Clay
> 
> Everything that eases recovery for whatever reason is something you
> have to pay attention to. The simplicity of ext{2,3} is something I
> really fail to find proper words for. As well as the really good fsck.
> Once seen a SIGSEGV'ing fsck, you really don't want to go there.
> 
> MfG, JBG
> 
> -- 
>        Jan-Benedict Glaw       jbglaw@...-owl.de                +49-172-7608481
>  Signature of:                       Eine Freie Meinung in einem Freien Kopf
>  the second  :                     für einen Freien Staat voll Freier Bürger.
-
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/