Re: "ls -l": Avoid unnecessary getxattr() overhead

[Sven Breuner]

Hi Jérémy,

thanks for running the tests.

Jérémy Compostella wrote on 02/06/2012 04:09 PM:
> As I'm stuck home today (unusual snow at Bordeaux, France), I made some
> tests:

Hm, Bordeaux - You're not working at the University, are you? Then you 
would even have access to a fhgfs file system to run the tests ;)

> 1. time ls -l>  /dev/null>  /dev/null (with a 10 thousands files in
>     current directory over NFS)
>
>    a) With coreutils 8.5-1
>
> real    0m4.242s
>
>    b) With coreutils devel 8.15
>
> real    0m4.162s

Ok, nfs was probably not the best example (my fault), as it just uses 
cached information and doesn't care much about revalidation. But there 
are certainly other file systems out there, fhgfs being one of them, 
which try to deliver up-to-date information and thus have to go an extra 
mile here.
My tests were based on a fhgfs benchmark with bonnie++, in which bonnie 
stat'ed all 60,0000 files in a directory in about 10-12 seconds and an 
"ls -l" in that directory took >30 seconds over a GigE connection on 
RHEL 6.2.


> 2. strace -c ls -l>  /dev/null (on the same directory)
>
>    a) With coreutils 8.5-1
> [...]
>
>    b) With coreutils devel 8.15
> [...]
>
> =>  First, it looks like that the devel version does not call getxattr()
> and lgetxattr() when unneeded.

I don't see any obvious commit with "git log src/ls.c" that could have 
changed this behaviour.
Did you compile coreutils 8.15 with selinux and acl support?

Best regards,
Sven