XFS unlink still slow on 3.1.9 kernel ?

[Richard Ems]

On 02/13/2012 06:15 PM, Christoph Hellwig wrote:
> 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
> 

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?
Is there another way to mount/create/mkfs the XFS to improve the unlink
time for this case?


Thanks again,
Richard


-- 
Richard Ems       mail: Richard.Ems at Cape-Horn-Eng.com

Cape Horn Engineering S.L.
C/ Dr. J.J. Dómine 1, 5º piso
46011 Valencia
Tel : +34 96 3242923 / Fax 924
http://www.cape-horn-eng.com