Hello, On 25/07/14 12:19, Rishi Agrawal wrote: > Hi, > One of our customer's application only needs file names not > file attributes. With directories having 10K+ inodes (assuming buffer > cache has directory blocks cached having file names, but inode > cache is limited and hence need eviction of older cached inodes), > older inodes are evicted periodically. So if they keep on doing > readdir(2) from NSF client on multiple directories, some directory's > files are periodically removed from inode cache and hence new > readdir(2) on same directory requires disk access to bring back > inodes again to inode cache. > > As READDIRPLUS request fetches attributes also, doing getattr on > each file on server, it causes unnecessary disk accesses. If > READDIRPLUS on NFS client is returned with -ENOTSUPP, NFS > client uses READDIR request which just gets the names of the files > in a directory, not attributes, hence avoiding disk accesses on server. > > Can this be per-export tunable so that different application can > use it in different ways, some supporting readdirplus and others > not supporting readdirplus? > > I have worked on a patch against 3.15.6 for this. Also I am > adding a patch against latest nfs-utils to have an export option > for this. Can someone let me know if these patches are adequate > or if any other changes are required. Patches attached, although > with minimal testing. I would like to know if something like this > can be added and if the patch can be reworked if I am missing > something for NFSv4. I just notice that the nfs-utils patch does not update the exports(5) man page. In that update please note this is a v3 only thing.... Not clear what we are going to do in the v4 case. Finally, please inline your patch posting in the your email as its is explained there https://www.kernel.org/doc/Documentation/SubmittingPatches It just makes it easier for everyone to do the review... tia, steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
