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: <5c49b0ed0607311556s50b77c07o150497f8e4bd3fd3@mail.gmail.com>
Date:	Mon, 31 Jul 2006 15:56:50 -0700
From:	"Nate Diller" <nate.diller@...il.com>
To:	"Jeff V. Merkey" <jmerkey@...fmountaingroup.com>
Cc:	"Gregory Maxwell" <gmaxwell@...il.com>,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"Clay Barnes" <clay.barnes@...il.com>,
	"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 7/31/06, Jeff V. Merkey <jmerkey@...fmountaingroup.com> wrote:
> Gregory Maxwell wrote:
>
> > On 7/31/06, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> >
> >> Its well accepted that reiserfs3 has some robustness problems in the
> >> face of physical media errors. The structure of the file system and the
> >> tree basis make it very hard to avoid such problems. XFS appears to have
> >> managed to achieve both robustness and better data structures.
> >>
> >> How reiser4 compares I've no idea.
> >
> >
> > Citation?
> >
> > I ask because your clam differs from the only detailed research that
> > I'm aware of on the subject[1]. In figure 2 of the iron filesystems
> > paper that Ext3 is show to ignore a great number of data-loss inducing
> > failure conditions that Reiser3 detects an panics under.
> >
> > Are you sure that you aren't commenting on cases where Reiser3 alerts
> > the user to a critical data condition (via a panic) which leads to a
> > trouble report while ext3 ignores the problem which suppresses the
> > trouble report from the user?
> >
> > *1) http://www.cs.wisc.edu/adsl/Publications/iron-sosp05.pdf
>
> Hi Gregory, Wikimedia Foundation and LKML?
>
> How's Wikimania going. :-)
>
> What he says is correct.  I have seen some serious issues with reiserfs
> in terms of stability and
> data corruption.  Resier is however FASTER, but the statement is has
> robustness issues is accurate.
> I was using reiserfs but we opted to make EXT3 the default for Solera
> appliances, even when using Suse 10
> due to issues I have seen with data corruption and hard hangs on RAID 0
> read/write sector errors.  I have
> stopped using it for local drives and based everything on EXT3.  Not to
> say it won't get there eventually, but
> file systems have to endure a lot of time in the field and deployment
> befor they are ready for prime time.
>
> The Wikimedia appliances use Wolf Mountain, and I've tested it for about
> 4 months with few problems, but
> I only use it for hosting the Cherokee Langauge Wikipedia.  It's
> performance is several magnitudes better
> than either EXT3 or ReiserFS.  Despite this, for vertical wiki servers,
> its ok to go out with, folks can specifiy
> whether they want appliances with EXT3, Reiser, or WMFS, but iit's a
> long way from being "cooked"
> completely, though it does scale to 1 exabyte FS images.

i've seen you mention the Wolf Mountain FS in other emails, but google
isn't telling me a lot about it.  Do you have a whitepaper?  are there
any published benchmark results?  what sort of workloads do you
benchmark?

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