On 8/20/2011 10:03 AM, Edward Ned Harvey wrote:
From: [email protected] [mailto:[email protected]]
On Behalf Of Doug Hughes

Ah, I think I know exactly what this (above) is.  Linux (CentOS) does
not fully implement the READDIRPLUS NFS RPC call, but Solaris does. When
the client asks for READDIRPLUS, the server fills in the packet with a
large number of replies and sends them in bulk. When the client asks for
READDIR, every single entry is enumerated as a single RPC which means
7000 RTTs. If you are using ls -l or ls -color, automatically double
that to 14000 RTTs because it will be doing getxattr and/or stat calls
for every entry. ouch!

So...  Can you just upgrade the version of the NFS client, or something like
that?  Perhaps download an auxiliary package from EPEL or RPMForge, or
something which isn't part of the mainstream RHEL/Centos repositories?

short of kernel hacking, there's nothing that I'm aware of that you can do about this (or maybe one of the newer 2.6.3* series has adjusted this, but I've never had much luck with stability of those kernels on CentOS, and I always regret going down that path)


I certainly know I can't settle for the default autofs4 that's included with
the distro.  Always upgrade to autofs5.  And install python2.6.  All of
which is unrelated, except to say a certain amount of upgrading above and
beyond what's included in the distro is absolutely necessary if you want a
system that doesn't suck...


Based on my quick search, it looks like ....  kernel, glibc, portmap,
nfs4-acl-tools, nfsutils...  Are the suspects.  I don't see any
significantly newer nfsutils or nfs4-acl-tools for centos5.  That's where I
stopped.  Didn't look any further for portmap, glibc, or what implications
it may have if you upgrade them.

As I recall, READDIRPLUS is a kernel implementation. it works closely with nfsutils, but I don't think changing nfsutils will help there, and certainly none of the others, unfortunately.


_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/

Reply via email to