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.
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.
NeilBrown
>
> > 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>
>
