On Thu, 2024-06-20 at 07:09 +1000, NeilBrown wrote: > On Wed, 19 Jun 2024, Jeff Layton wrote: > > On Wed, 2024-06-19 at 17:10 +1000, NeilBrown wrote: > > > On Wed, 19 Jun 2024, Christoph Hellwig wrote: > > > > What happened to the requirement that all protocol extensions added > > > > to Linux need to be standardized in IETF RFCs? > > > > > > > > > > > > > > Is that requirement documented somewhere? Not that I doubt it, but it > > > would be nice to know where it is explicit. I couldn't quickly find > > > anything in Documentation/ > > > > > > Can we get by without the LOCALIO protocol? > > > > > > For NFSv4.1 we could use the server_owner4 returned by EXCHANGE_ID. It > > > is explicitly documented as being usable to determine if two servers are > > > the same. > > > > > > For NFSv4.0 ... I don't think we should encourage that to be used. > > > > > > For NFSv3 it is harder. I'm not as ready to deprecate it as I am for > > > 4.0. There is nothing in NFSv3 or MOUNT or NLM that is comparable to > > > server_owner4. If krb5 was used there would probably be a server > > > identity in there that could be used. > > > I think the server could theoretically return an AUTH_SYS verifier in > > > each RPC reply and that could be used to identify the server. I'm not > > > sure that is a good idea though. > > > > > > > My idea for v3 was that the localio client could do an O_TMPFILE create > > on the exported fs and write some random junk to it (a uuid or > > something). Construct the filehandle for that and then the client could > > try to issue a READ for that filehandle via the NFS server. If it finds > > that filehandle and the contents are correct then you're on the same > > host. Then you just close the file and it should clean itself up. > > I can't see how this would work, but maybe I don't have a good enough > imagination. > Maybe I didn't explain it well: Basically the idea was to create a "unique" file in a filesystem exported by the local nfsd, and then see if it's accessible at the expected filehandle via a v3 READ and has the expected contents. If it is then you can assume localio is possible. O_TMPFILE would just make it simple to clean up the file after you were done, and would avoid adding spurious entries to the exported directory tree. The problem with that method is that it's hard to make it work well with containers. You'd need to be able to predict which net namespace's server you were talking to, or somehow make the file be exported by all of them. That alone makes it difficult to implement. > The high-level view of the proposed protocol is: > - client asks remote server to identify itself. > - server returns an identity > - client uses local-sideband to ask each local server if it has the > given identity. > > I don't see where an O_TMPFILE could fit into this, or how a different > high-level approach would be any better. > > For NFSv3 the client could ask with a new Program or Version or > Procedure, or all three. Or it could ask with a new file-handle or path > name. I imagine using a webnfs (rfc2054) multi-component lookup on the > public filehandle for "/linux/config/server-id" and getting back a > filehandle which encodes the server ID somehow. All these seem credible > options and it is not clear than any one is better than any other. > > For NFSv4.1 I think that LOCALIO looks a lot like trunking and so using > exactly the same mechanism to determine if two servers are the same is a > good idea. > But then LOCALIO also looks a lot like a new pNFS/DS protocol so maybe > we should specify that protocol and use GETDEVICELIST or GETDEVICEINFO > to find the identity of the server. > > > > > This is a little less straightforward and efficient than the localio > > protocol that Mike is proposing, but requires no protocol extensions. > > I think that if we use anything other than the server-id in the > EXCHANGE_ID response, then we are defining a new protocol as it is a new > request which we expect existing servers to ignore or fail, even though > they have never been tested to ignore/fail that particular request. > > Of all the options I would guess that a new version for an existing > protocol would be safest as that is the most likely to have been tested. > A new RPC program is probably conceptually simplest. A little hack in > LOOKUPv3 to detect the public filehandle etc is probably the easiest to > code, and a new pnfs/ds protocol is probably the cleanest overall > except that it doesn't support NFSv3. > > My purpose in all this is not to replace Mike's LOCALIO protocol, but to > explore the solution space to ensure there is nothing that is obviously > better. As yet, I don't think there is. > > Agreed. Thanks for laying out some alternatives! It's good to consider other possibilities. > > > > > Going through the IETF process for something that is entirely private to > > > Linux seems a bit more than should be necessary.. > > > > > > > Agreed. Given that this our own protocol extension and we don't have > > any expectation of other clients or servers implementing this, I don't > > see the point. I do agree that trying to avoid program number conflicts > > is a good thing though. > > -- > > Jeff Layton <jlayton@xxxxxxxxxx> > > > -- Jeff Layton <jlayton@xxxxxxxxxx>
