Re: NFS Performance on Linux 2.2.19 (RedHat version) -- lstat64() ?

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Joe Pranevich <Joe.Pranevich@corp.terralycos.com> writes:

     > but not in a precise testing environment. Where my confusion
     > comes in is that a simple "ls" against a directory with a
     > couple files takes approximately 4-5 times as long under Linux
     > as on Solaris. Doing a "strace -c" on the ls process shows that
     > nearly all of the time is being spent in lstat64(). (And yes, I
     > was using "ls --color=none" :) ) (Our application does a lot of
     > similar operations, so this is a valid test.)

Hi,

  Solaris is currently more efficient than we are when it comes to
filehandle and attribute caching, but together with Chuck Lever, we
worked hard over the summer to even the odds.

  My main suspect for your report is the NFSv3 operation
READDIRPLUS. Whereas ordinary NFSv2/v3 READDIR returns only the
filename + inode number for each directory entry, READDIRPLUS also
returns the NFS filehandle and full file attributes. With proper
caching, this is sufficient to save an entire LOOKUP RPC call per file
when you get to the stat() calls...

  I do have patches that you can test, though unfortunately only for
the 2.4. series. A backport to the 2.2.x series should be possible if
you're able and willing, but my own schedule unfortunately won't
permit it.
As far as I know, the 2.4 patches can be considered `production
quality' (meaning that I haven't seen any bugs reported over the last
couple of months), and I've been using them in production on our own
machines.

If you are interested, please first apply the attribute cache
improvements in

  http://www.fys.uio.no/~trondmy/src/2.4.16/linux-2.4.15-cto.dif

and then the readdirplus implementation in

  http://www.fys.uio.no/~trondmy/src/2.4.16/linux-2.4.15-rdplus.dif

Cheers,
   Trond