Work

[Valdis.Kletnieks at vt.edu]

On Fri, 25 Jul 2014 15:23:42 -0700, Arlie Stephens said:

> If you want an annoying problem, explain and/or fix directory
> performance on ext4. I've got a server where an ls of a directory took
> 5 seconds, according to "time", even though it only has 295 entries at
> present.

I don't suppose you could get a trace of where that ls is spending its
time with the kernel's trace facilities, or even just getting a stack trace
of where that ls is in the kernel?

I'll go out on a limb and ask if a *second* ls of the same directory runs
quickly because it's now cache-hot.  If so, I'd start looking at whether
there's large amounts of *other* disk activity going on, and the reads of the
directory are getting hung in the I/O queue behind other disk read/writes.

Also, are you doing an 'ls' (which just requires reading the name/inode#
pairs), or an 'ls -l' whihc in addition requires a stat() call to read in the
inode itself)?  That makes a lot of difference.  Cache-cold on my laptop, and a
*huge* Mail/linux-kernel directory (yes, it really *is* an 11M directory,
it's got a half-million entries in it):

[~] echo 3 >| /proc/sys/vm/drop_caches
[~] cd Mail
[~/Mail] time ls linux-kernel/ | wc -l
478401

real    0m2.387s
user    0m0.500s
sys     0m0.433s
[~/Mail] ls -ld linux-kernel/
drwxr-xr-x. 2 valdis valdis 11005952 Jul 25 19:30 linux-kernel/
[~/Mail] time ls -l linux-kernel/ | wc -l
478402

real    0m32.915s
user    0m2.483s
sys     0m20.787s

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140725/e1d11ecd/attachment.bin