[Top] [All Lists]

Re: XFS status update for August 2010

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS status update for August 2010
From: Willy Tarreau <w@xxxxxx>
Date: Sun, 5 Sep 2010 20:56:00 +0200
Cc: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20100905130809.GI705@dastard>
References: <20100902145959.GA27887@xxxxxxxxxxxxx> <20100905074457.GC16004@xxxxxx> <201009051137.07678@xxxxxx> <20100905104739.GC27623@xxxxxx> <20100905130809.GI705@dastard>
User-agent: Mutt/
On Sun, Sep 05, 2010 at 11:08:09PM +1000, Dave Chinner wrote:
> On Sun, Sep 05, 2010 at 12:47:39PM +0200, Willy Tarreau wrote:
> > On Sun, Sep 05, 2010 at 11:37:03AM +0200, Michael Monnerie wrote:
> > > On Sonntag, 5. September 2010 Willy Tarreau wrote:
> > > > I've just installed
> > > 
> > > Try the following mount options: 
> > > relatime,logbufs=8,logbsize=256k,attr2,barrier,largeio,swalloc,delaylog
> FYI:
>       - relatime,logbufs=8,attr=2,barrier are all defaults.

in fact I already had noatime and logbsize=256k, and remembered having
played with the other ones in the past.

>       - largeio only affects stat(2) output if you have
>         sunit/swidth set - unlikely on a laptop drive, and has
>         no effect on unlink performance.
>       - swalloc only affects allocation if sunit/swidth are set
>         and has no effect on unlink performance.


> > Ah thanks for the info Michael, indeed it's a *lot* better: down from 57s
> > to 1.3s !
>       - delaylog is the option providing that improvement.

That's what I deduced from Christoph's initial description.

> You should keep in mind that delaylog is a brand new experimental
> feature (as it warns in dmesg output on mount)

yes, I've noticed the warning in the code then in dmesg. It does not
seem to be considered upon a remount (I did a mount -o remount,delaylog /
and it did nothing).

> and as such has the potential to eat your data.

noted, thanks for the warning.

> That being said, I've been running
> my laptop and my production machines (except for the backup target)
> for a couple of months now with it and haven't had any problems...

Fine, this is typically the type of info I need. Thus I'll be using
it with an eye on any potential FS-related problem.

Are there any plans to use that option by default once it gets enough
testing ? I'm asking because I had to convert from XFS to reseirfs at
least twice due to slow metadata, but I tend to trust XFS a lot more
(especially due to dirty failures I experienced a few years ago with
reiserfs - corrupted file tails upon power cut).


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