On Mon, 2024-08-26 at 14:16 +0000, Chuck Lever III wrote: > > > > On Aug 25, 2024, at 9:56 PM, NeilBrown <neilb@xxxxxxx> wrote: > > > > On Sat, 24 Aug 2024, Mike Snitzer wrote: > > > + > > > +6. Why is having the client perform a server-side file OPEN, > > > without > > > + using RPC, beneficial? Is the benefit pNFS specific? > > > + > > > + Avoiding the use of XDR and RPC for file opens is beneficial > > > to > > > + performance regardless of whether pNFS is used. However > > > adding a > > > + requirement to go over the wire to do an open and/or close > > > ends up > > > + negating any benefit of avoiding the wire for doing the I/O > > > itself > > > + when we’re dealing with small files. There is no benefit to > > > replacing > > > + the READ or WRITE with a new open and/or close operation that > > > still > > > + needs to go over the wire. > > > > I don't think the above is correct. > > I struggled with this text too. > > I thought the reason we want a server-side file OPEN is so that > proper access authorization, same as would be done on a remote > access, can be done. > You're conflating "server-side file open" with "on the wire open". The code does do a server side file open, and does call up to rpc.mountd to authenticate the client's IP address and domain. The text is basically pointing out that if you have to add stateful on- the-wire operations for small files (e.g. size < 1MB), then you might as well just send the READ or WRITE instead. > > > The current code still does a normal NFSv4 OPEN or NFSv3 GETATTR > > when > > then client opens a file. Only the READ/WRITE/COMMIT operations > > are > > avoided. > > > > While I'm not advocating for an over-the-wire request to map a > > filehandle to a struct nfsd_file*, I don't think you can > > convincingly > > argue against it without concrete performance measurements. > What is the value of doing an open over the wire? What are you trying to accomplish that can't be accomplished without going over the wire? -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
