== NFS directory reading and directory file type information NFS has always had an operation to read directories (unsurprisingly called _READDIR_). In NFS v2, this operation simply returned a list of names (and 'fileids', ie inode numbers). One of the things that NFS v3 introduced was an extended version of this, called _READDIRPLUS_ that returns some additional information along with the directory listing. This new operation was motivated by the observation that NFS clients often immediately followed a _READDIR_ operation by a bunch of additional NFS calls to get additional information on many or all of the names in the directory. In light of the fact that [[file type information is available in Unix directories DirectoryDTypeHistory]] at least some of the time (on many Unixes), I found myself wondering if this file type information was sufficient for an NFS server to implement _READDIRPLUS_, so that such a Unix could satisfy _READDIRPLUS_ requests purely from reading the directory itself. As far as I can see, unfortunately the answer is that it isn't. Directory file type information only gives you the file type of each name, while NFS v3's _READDIRPLUS_ operation is specified in [[RFC 1813 https://tools.ietf.org/html/rfc1813]] as returning full information on each name, what the standard calls a _fattr3_ (defined on page 22). This is basically the same as what you get from _stat()_, and this implies that the NFS server has to read each inode to pull up this information. That's kind of a pity, at least for NFS v3, and one of the consequences is that you can't get the same type of high-efficiency file type scanning over NFS v3 as you can locally. We have historically used NFS v3 only and so I default to mostly looking at it. However, there's also NFS v4 (specified in [[RFC 7530 https://tools.ietf.org/html/rfc7530]]), and once I looked at it, it turns out to be different in an important way. NFS v4 has only a _READDIR_ operation, but it has been defined to allow the NFS client to specify what attributes of each name it wants to get back. A NFS v4 client can thus opt to ask for only fileids and file type information, which permits an NFS v4 server to satisfy the _READDIR_ request purely from reading the directory, without having to _stat()_ each file in the directory. Even in [[the possible case where file type information isn't known for all files ../solaris/ZFSAndDirectoryDType]], the NFS v4 server would only have to _stat()_ some files, not all of them. With that said, I don't know if NFS v4 clients actually make such limited _READDIR_ requests or if they actually ask NFS v4 servers to give them enough extra information that the server has to _stat()_ everything. Sadly, one thing clients could sensibly want to know to save time is the NFS filehandle of each name, and [[the filehandle generally requires information that needs a _stat()_ NFSFilehandleInternals]]. (Learning this about NFS v4 may make us more interested in trying to use it, assuming that we can make everything work in NFS v4 with traditional '_sec=sys_' Unix style 'trust the client's claims about UIDs and GIDs' security.)