Subject: RE: [nfsv4] Validation of migrated clientids

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 21 Mar 2006 11:41:34 -0500

> If the client thinks it is two different servers (and it likely will),
> but the server thinks it is one client, then I can imagine confusion
> reigning. 

OK, I can see that agreement between the client and server could be
more important than agreement with reality.

> > No it won't.  The client that would be using the same nfs_client_id 
> > would be using the same verifier and so the server would not see a client 

> Why do you think the client will use the same verifier?

a) Because it is the simplest thing to do.

b) The spec says that a verifier indicates incarnation of a client and
   if the nfs_client_id4's indicate the same client then there is no
   reason to indicate that we have anything but one single common 
   incarnation of that client.

c) Do anything else would cause things to break.

> > It seems wrong to me when you have one server and one client, for the
> > server to think there are two clients and the client to think there are
> > two servers.  It seems like it would have all sorts of nasty consequences.

> In NFSv4.0 without a serverid, I 
> don't see how to solve the problem 
> of the client and server agreeing a 
> set of server network addresses refers
> to the same serverid. 

OK, so let's make sure we deal with this in v4.1.

> And having 
> the client use reverse DNS to assume
> a set of network addresses refers to the same 
> server is nasty for some server architectures
> that don't share a uniform memory address space.

The trunking stuff that is mentioned in the current draft does assume
that the client knows about the equivalence of network addresses 
(when they identify the same server) through external means (such as 
DNS).  I know Tom is thinking about this issue.

Also note that CREATECLIENTID indicates that an nfs_client_id4 is
to be sent.  If you follow the existing v4.0 instructions for 
constructing that you run into situation in which because of loss
of a network address, the clientid you created for one instance
of client will not match the one created for a subsequent instance
(different nfs_client_id4), just as in Bruce's scenario.  

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]]
Sent: Monday, March 20, 2006 12:10 AM
To: Noveck, Dave; J. Bruce Fields
Cc: [email-masked]; [email-masked]
Subject: RE: [nfsv4] Validation of migrated clientids

--- "Noveck, Dave" <[email-masked]> wrote:

> >From section 8.1.1 of RFC 3530.
> 
> >   o  The string should be different for each server network address
> >      that the client accesses, rather than common to all server network
> >      addresses.  
> 
> OK, I see what you're referring to.
> 
> >      The reason is that it may not be possible for the
> >      client to tell if the same server is listening on multiple network
> >      addresses.  If the client issues SETCLIENTID with the same id
> >      string to each network address of such a server, the server will
> >      think it is the same client, 
> 
> And in fact it is the same client.  Normally, the server thinking something
> is gtrue when it is in fact true is not a bad thing.

If the client thinks it is two different servers (and it likely will),
but the server thinks it is one client, then I can imagine confusion
reigning. 

> >      and each successive SETCLIENTID will
> >      cause the server to begin the process of removing the client's
> >      previous leased state.
> 
> No it won't.  The client that would be using the same nfs_client_id 
> would be using the same verifier and so the server would not see a client 

Why do you think the client will use the same verifier? But let's assume
it does ...

> reboot but would see the client updating his callback his information, 
> and since the callback is presumably not changing the null update of 
> that information would be a no-op.

The client still thinks he's dealing with two different servers. So when he uses
the same open_owner to open files on "each" server, the single server thinks
it is dealing with one client and sends sequence number errors back to the
client.
> 
> Does anyone know another reason why this should be done (other than the
> spec says so, I mean)?
> 
> It seems wrong to me when you have one server and one client, for the
> server to think there are two clients and the client to think there are
> two servers.  It seems like it would have all sorts of nasty consequences.

In NFSv4.0 without a serverid, I 
don't see how to solve the problem 
of the client and server agreeing a 
set of server network addresses refers
to the same serverid. And having 
the client use reverse DNS to assume
a set of network addresses refers to the same 
server is nasty for some server architectures
that don't share a uniform memory address space. 

> -----Original Message-----
> From: J. Bruce Fields [mailto:[email-masked]]
> Sent: Sunday, March 19, 2006 1:42 PM
> To: Noveck, Dave
> Cc: [email-masked]; [email-masked]
> Subject: Re: [nfsv4] Validation of migrated clientids
> 

> One example: suppose a client migrates and succesfully uses its old
> state with the new server, then the new server reboots.  In order for
> the new server to meet the requirements of 8.6.3 ("Network Partitions
> and Recovery"), it has to be able to identify the SETCLIENTID's that
> come in after reboot as originating from the client that migrated to it
> before the reboot.

Section 8.6.3 says the server at minimum has to keep in stable storage the
nfs_client_id4.id if it wants to avoid the edge conditions. 

> 
> But 8.1.1 says that the client-generated identifier presented in the
> SETCLIENTID should vary depending on the IP address of the server.  So
> there's no way that the new server can know the identifier that the
> migrated client is going to present after reboot.

The reason for 8.1.1 is as I've already explained. Since the client knows
the server that had the volume is not the same as the server that now
has the volume, no worries about the new server returning
strange sequencing errors. So the client is free to use the nfs_client_id4.id 
it gave to the first server before it migrated the file system.
> 
> Should the client keep its old client identifier in this case?  (And how
> do we make that work over client reboots?)

Barring a protocol change, to avoid having to wait it its previously
held state to lease-timeout, the client would need to record somewhere that
for the migrated volume it was using a nfs_client_id4.id string derived from
the old NFS server. 

In NFSv4.1 we may want to add serverids, and thus obviate 
the need to derive nfs_client_id4.id's from server addresses.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4