xfs
[Top] [All Lists]

Re: XFS unlink still slow on 3.1.9 kernel ?

To: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>
Subject: Re: XFS unlink still slow on 3.1.9 kernel ?
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 13 Feb 2012 12:29:37 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <4F3947D6.5060402@xxxxxxxxxxxxxxxxx>
References: <4F394116.8080200@xxxxxxxxxxxxxxxxx> <20120213170825.GA7197@xxxxxxxxxxxxx> <4F394442.9020307@xxxxxxxxxxxxxxxxx> <20120213171556.GA13449@xxxxxxxxxxxxx> <4F3947D6.5060402@xxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Feb 13, 2012 at 06:26:46PM +0100, Richard Ems wrote:
> YES. All files (and dirs) that I checked do show something as
> 
> 0: [0..7]: 18531216..18531223
> 
> So, what improvements can I expect from a kernel > 3.2 ?
> Can I read somewhere about the changes/patches introduced?

On some crazy workloads I've seen speedups up to a factor of 10.000 (5
orders or magnitude).  You probably won't get that much of a speedup,
but it will still be significant.

The patch in mainline for this is:

commit 859f57ca00805e6c482eef1a7ab073097d02c8ca
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date:   Sat Aug 27 14:45:11 2011 +0000

    xfs: avoid synchronous transactions when deleting attr blocks

> Is there another way to mount/create/mkfs the XFS to improve the unlink
> time for this case?

Try increasing the inode size during filesystem creating using the
"-i size=512" option or even "-i size=1024" if you still have
out of line attributes.  The should give you even bigger speedups
for this workload than the patch above.

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