On Sun, 9 Aug 2015 00:17:02 -0700 Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Wed, Aug 05, 2015 at 05:13:22PM -0400, Jeff Layton wrote: > > Currently, NFSv2/3 reads and writes have to open a file, do the read or > > write and then close it again for each RPC. This is highly inefficient, > > especially when the underlying filesystem has a relatively slow open > > routine. > > .. as do many NFSv4 reads and writes as they often get special stateids > passed from the client. Seems a little odd that we take more care > of this for the legacy protocols than the current one. > This is just an initial step. I'd like to see the nfs4_file cache layered on top of this eventually. That's a bit more work though, and I wanted to get this piece merged first before I did that part. > I think I'd rather see a nfs4_file cache and turn v2/3 into something > like the special stateid case. Did you consider that? I started looking at extending the nfs4_file cache to NFSv2/3, but it's actually rather difficult... We traditionally haven't dealt with share/deny modes in NFSv3, so we'd need a mechanism to bypass all of that stuff for legacy protocols. We'd also have to convert that cache from one that frees objects when the last one is put to one that keeps them around for a bit. That also means that the v2/3 opens have to keep around extra fields that aren't really needed, and deal with the really godawful locking of the NFSv4 code. I really think this approach is a better one. We can still use this cache from the NFSv4 code and wiring it in shouldn't be too hard. It's mostly a matter of plumbing in struct nfsd_file objects where that code is passing around struct file objects now. -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- 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
