[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1154382026.7230.110.camel@localhost.localdomain>
Date: Mon, 31 Jul 2006 22:40:26 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Gregory Maxwell <gmaxwell@...il.com>
Cc: 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
Ar Llu, 2006-07-31 am 17:00 -0400, ysgrifennodd Gregory Maxwell:
> 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?
Two sources, the cases I've looked at myself when IDE maintainer and
also comments Hans made when we met at UKUUG a few years ago. Generally
speaking on an IDE failure that lost chunks of disk the ext2/ext3 users
got most of their data back. The reiserfs ones sometimes got it back and
sometimes got catastrophic failure.
The ext3 fsck is extremely effective in the face of serious errors. Some
of that is clever code that knows about things like rewriting inode
blocks to force reallocation of failed metadata by the drive but the
majority of it is simply because you *know* where inode X is on the disk
rather than having to deal with data structures and walk them.
That's a tradeoff with the reiser performance with small files and until
recently the reiser large directory performance. Which is right is
another question altogether. Its also something I think XFS demonstrates
can be done better so doesn't invalidate the theory behind reiserfs just
the rev 3 implementation.
> 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?
man mount
Ext3 is configurable, and has been for years via the errors= option.
Alan
-
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