Some people object to nfsv3 because certain operations cause the server to execute stat() on the file being handled at that time. This can lead to measurable performance differences between the two protocols.

I.e., the NFS V3 READDIRPLUS operation causes the server to do more work to get the file handles and file attributes of the files whose names it's sending over the wire, and to send more stuff over the wire in the reply; the client then has to do more work to process those file handles and file attributes.

If the client is then going to actually *use* the file handles and file attributes of enough of those files, that's not an issue, because with READDIR (which is all you have in V2) it'd have to make subsequent LOOKUP and GETATTR calls to get that information for those files *anyway*. Consider, for example, a UNIX "ls -l" on a directory, where READDIRPLUS probably buys you something.

However, if it *doesn't* use them, you've just wasted server resources, network bandwidth, and client resources. Karl Swartz probably remembers the netnews situation he found where the client was reading a directory and cared only about the names of the file in the directory (I don't).

We may be able to improve our READDIRPLUS handling (I filed a bug on that a while ago), but that doesn't remove the server overhead, it just reduces it, and it makes no change to the network or client overhead. It may also be possible to have clients do a better job of figuring out whether to use READDIR or READDIRPLUS with NFS V3; I don't know which V3 clients, if any, could be so improved, nor do I know which ones have been so improved.