Subject: RE: [nfsv4] Validation of migrated clientids

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 19 Mar 2006 17:45:50 -0500

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

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

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.

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

On Sun, Mar 19, 2006 at 11:02:45AM -0500, Noveck, Dave wrote:
> As far as the first of these concerns, I believe that fs_location_info,
> as proposed would address this in v4.1.
> 
> >    o    The same-state mask indicates, in combination with the
> >          appropriate location ids, whether two replicas will have the
> >          same state environment.  This does not necessarily mean that
> >          when performing migration, the client will not have to reclaim
> >          state.  However it does mean that the client may proceed using
> >          his current clientid just as if there were no migration event
> >          and only reclaim state when an NFS4ERR_STALE_CLIENTID or
> >          NFS4ERR_STALE_STATEID error is received.
> 
> Where the same-state mask indicates no possibility of state sharing the
> client would know that use and checking of an existing clientid would
> not be supported, and so you would avoid the possiblity of inadvertantly
> running into valid stateid by accident.  

Yep, that sounds fine.

> I don't quite understand the second issue, specifically the phrase
> "due to the use of server ip addresses" so I'm not sure if the
> fs_location_info stuff might help there as well.

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.

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.

Should the client keep its old client identifier in this case?  (And how
do we make that work over client reboots?)

In general we're worried about what problems might be caused by the lack
of a way to track a client across migration events.

--b.

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

---

From: Mike Eisler <[email-masked]>
Date: Sun, 19 Mar 2006 21:09:53 -0800 (PST)

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

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

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

> come in after reboot as originating from the client that migrated to it

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. 

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