Re: slow ls -l

xfs

Re: slow ls -l

To:	Linux fs XFS <xfs@xxxxxxxxxxx>
Subject:	Re: slow ls -l
From:	pg@xxxxxxxxxxxxxxxxxxx (Peter Grandi)
Date:	Tue, 12 Nov 2013 23:31:41 +0000
Delivered-to:	xfs@xxxxxxxxxxx
In-reply-to:	<5282A3CA.4040005@xxxxxxxxxxxxxxx>
References:	<526EAFD1.1030500@xxxxxxxxxxxxxxx> <526F7600.8060102@xxxxxxxxxxxxxxxxx> <526FC027.3040906@xxxxxxxxxxxxxxx> <526FC84D.7070905@xxxxxxxxxxxxxxxxx> <5273FCCB.60601@xxxxxxxxxxxxxxx> <527741BF.1000309@xxxxxxxxxxxxxxxxx> <52827024.8020705@xxxxxxxxxxxxxxx> <5282A3CA.4040005@xxxxxxxxxxxxxxx>

> [ ... ] "ls -l" communicating with the System Security
> Services Daemon (SSSD) to (I imagine) look up user and group
> names. [ ... ]

Good guess...

> [ ... ] Your "df" performance problem may be caused by
> something completely different.

I think that was 'du', as 'df' should be nearly instantaneous,
except in rare cases where in some filesystems there are
allocations "in flight" and getting an exact count of free
blocks (including metadata for example ...) requires waiting for
some large IO to complete. Can't remember whether XFS is among
those.

[More with this subject...]

<Prev in Thread]	Current Thread	[Next in Thread>
slow ls -l, Qing Chang Re: slow ls -l, Stan Hoeppner Re: slow ls -l, Qing Chang Re: slow ls -l -- could use a little help to finish this one up, Stan Hoeppner Re: slow ls -l -- could use a little help to finish this one up, Jay Ashworth Re: slow ls -l -- could use a little help to finish this one up, Peter Grandi Re: slow ls -l, Nathaniel W. Turner Re: slow ls -l, Peter Grandi <= Re: slow ls -l, Peter Grandi Re: slow ls -l, Dave Chinner Re: slow ls -l, Qing Chang

Previous by Date:	Re: slow ls -l, Peter Grandi
Next by Date:	Re: slow ls -l -- could use a little help to finish this one up, Peter Grandi
Previous by Thread:	Re: slow ls -l, Nathaniel W. Turner
Next by Thread:	Re: slow ls -l, Peter Grandi
Indexes:	[Date] [Thread] [Top] [All Lists]