[Top] [All Lists]

Re: fsck.xfs proposed improvements

To: Andi Kleen <andi@xxxxxxxxxxxxxx>
Subject: Re: fsck.xfs proposed improvements
From: Mike Ashton <mike@xxxxxxxx>
Date: Thu, 23 Apr 2009 09:49:00 +0100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <87ws9cnz14.fsf@xxxxxxxxxxxxxxxxx>
References: <mailman.0.1240318659.128675.xfs@xxxxxxxxxxx> <20090421142333.GA5197@xxxxxxxx> <49EE441E.6040606@xxxxxxxxxxx> <20090422094527.GA16600@xxxxxxxx> <87ws9cnz14.fsf@xxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Wed, Apr 22, 2009 at 11:45:11PM +0200, Andi Kleen wrote:
> Mike Ashton <mike@xxxxxxxx> writes:
> > With badly behaved hardware,
> > which seem prevalent, or any bugs which do get into xfs we could
> > actually end up with xfs being less fault tolerant and less reliable
> > in general use than other filesystems, which would be a bit of a
> > shame.
> Most Linux file systems are not very fault tolerant in this sense;
> e.g. on ext3 you have have to press return and accept lots of scary
> messages to get through fsck.

Perhaps, but anecdotally/subjectively I've never had a ext3 based
system fail to boot because I turned it off and on again.  I've had
this happen with xfs root filesystems about 15 times over the past few
years.  I'm getting to the point where I'm starting to question the
wisdom of choosing xfs for my systems - whether it's actually mature
enough for use in server environments - which given that it's the one
which ought to be a total no-brainer in this respect, is a worry.

I think even if I can't persuade you guys to make official
improvements, I've got enough information to make ad-hoc improvements
to my own systems, but I'm going to have a hard time on the advocacy
front.  xfs rocks, but a system is only as good as its last power cut
(or something).

I'm hopeful that my readonly/norecovery tuning idea might catch
someone's imagination, but we'll have to see.


<Prev in Thread] Current Thread [Next in Thread>