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 126.96.36.199
> > >
> > > Try the following mount options:
> > > relatime,logbufs=8,logbsize=256k,attr2,barrier,largeio,swalloc,delaylog
> - 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).