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. This is a little less straightforward and efficient than the localio protocol that Mike is proposing, but requires no protocol extensions. > 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>
