Date: Mon, 13 Feb 2012 12:15:56 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Richard Ems <richard.ems@cape-horn-eng.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
Subject: Re: XFS unlink still slow on 3.1.9 kernel ?
Message-ID: <20120213171556.GA13449@infradead.org>
References: <4F394116.8080200@cape-horn-eng.com>
 <20120213170825.GA7197@infradead.org>
 <4F394442.9020307@cape-horn-eng.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4F394442.9020307@cape-horn-eng.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Mon, Feb 13, 2012 at 06:11:30PM +0100, Richard Ems wrote:
> On 02/13/2012 06:08 PM, Christoph Hellwig wrote:
> > On Mon, Feb 13, 2012 at 05:57:58PM +0100, Richard Ems wrote:
> >> This is a backup system running dirvish, so most files in the dirs I am
> >> removing are hard links. Almost all of the files do have ACLs set.
> > 
> > How many ACLs do you usually have set?  If they aren't stored inline
> > but need to go out of the inode unlinks will be extremly slow for
> > kernels before v3.2.
> > 
> 
> Almost all dirs and files there do have ACLs set.
> Each of them do have about 10 user ACLs and 10 default ACls.
> Is that too many?
> Is this then the reason for being that slow?

That doesn't sound like a lot to me, but instead of guessing around,
let's just check the actual facts.

Does "xfs_bmap -a" for the kind of files you are deleting show any
extents? If it doesn't the output will look like:

# xfs_bmap -a internal
internal: no extents

if it has any it will look like:

# xfs_bmap -a external
external:
	0: [0..7]: 8557712..8557719