coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jérémy Compostella
Subject: Re: "ls -l": Avoid unnecessary getxattr() overhead
Date: Mon, 6 Feb 2012 20:00:44 +0100

2012/2/6 Sven Breuner <address@hidden>
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 ;)
No, I don't. 

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?
Looking at config.log, I can affirm that I don't compile with both of them ... ;)
And that perfectly explain what I did not find any commit relative to this too.

Anyway, you should maybe provide a "strace -c" output in both cases in order to know
how much would be the speed improvement.

Cheers,

Jérémy


reply via email to

[Prev in Thread] Current Thread [Next in Thread]