Subject: Re: still more CLID_INUSE

From: Peter Astrand <[email-masked]>
Date: Fri, 19 Jul 2002 00:17:49 +0200 (CEST)

On Thu, 18 Jul 2002, Spencer Shepler wrote:

> On Fri, Peter Astrand wrote:
> > 
> > To minimize the problems with two clients using the same clientid, servers
> > can track the client IP adress and put some WARNING messages in its log
> > files when the IP changes, but I don't think a different IP should
> > generate CLID_INUSE.
> 
> I would like to understand what environment you are thinking that a
> client will want to change its IP address and continue to use the same
> nfs_client_id4.id value between those two IP addresses.

The spec already gives an example: 

"For example, a High Availability configuration where the nfs_client_id.id
is derived from the ethernet controller address"

If the client uses the ethernet controller address as nfs_client_id.id, it 
is totally independent of the IP. 

Another way of constructing the nfs_client_id4.id (which makes more sense
to me) is to use the FQDN hostname. This does not change either when you 
change IP adress. 

How does the Solaris or Linux client construct the clientid?

-- 
/Peter Åstrand <[email-masked]>

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 18 Jul 2002 17:36:03 -0500

> is totally independent of the IP. 

That is an example of how the nfs_client_id4.id could be incorrectly
configured.

The example I am thinking of is the case that a client is a dhcp
client and it reboots and changes IP addresses but constructs the
nfs_client_id4.id such that it is independent of the IP address.

> to me) is to use the FQDN hostname. This does not change either when you 

But that alone is not enough to differentiate the client as has been
discussed.

> How does the Solaris or Linux client construct the clientid?

The Solaris client uses a combination of:
	hostname of client
	a string identifying the client as the Solaris NFSv4 kernel
	the ip address of the server

The reason the ip address of the server is present is to allow for a
multi-homed server.  If the client does not do this, the client can
mount the same portion of the server name space in two places at the
client from two server interfaces and the server will potentially
release state incorrectly.  If the client doesn't know that the two
server interfaces are the same server, it will not manage the state
correctly.  Delegation is one area where there can be confusion.

-- 
Spencer

---

From: Peter Astrand <[email-masked]>
Date: Fri, 19 Jul 2002 00:50:28 +0200 (CEST)

> That is an example of how the nfs_client_id4.id could be incorrectly

What is incorrect in the example is that one have configured two clients
with the same nfs_client_id4.id. What I mean is that you can have one
single client that constructs its nfs_client_id4.id from the MAC adress
and that client may want to change IP.

> nfs_client_id4.id such that it is independent of the IP address.

Yes, this is a good example. 

> But that alone is not enough to differentiate the client as has been

If there is a general consensus of that nfs_client_id4.id should include 
portions of the transport layer IP adress, I think this should be 
mentioned in the spec. 

> 	the ip address of the server

This nfs_client_id4.id looks independent of the IP adress to me. And your
server returns CLID_INUSE if the client IP changes? Then, how do you
change IP of the client, without getting CLID_INUSE?

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 18 Jul 2002 19:10:52 -0500

> portions of the transport layer IP adress, I think this should be 

There is consensus that nfs_client_id4.id should be as unique as
possible.  Stating that it must contain an IP address it not necessary.

> change IP of the client, without getting CLID_INUSE?

It doesn't.  The client will receive CLID_INUSE and in the current
implementation will error out of the operation (I will be opening a
bug on the Solaris code to have it wait a server lease period and
retry the operation).  

For the case of a client's use of DHCP and the switching of IP
addresses between reboots, I don't think this will occur that often
that the client can't handle the CLID_INUSE error as I have described.

-- 
Spencer

---

From: Peter Astrand <[email-masked]>
Date: Fri, 19 Jul 2002 10:47:42 +0200 (CEST)

> bug on the Solaris code to have it wait a server lease period and

If your Solaris server releases the clientid after a lease period, then
this will work fine.  But according to the current spec, servers are not
required to do so.  Servers can keep the clientid forever, which means the
client would retry and get CLID_INUSE forever.  Or at least until some
administrator manually clears the clientid, if this is possible with the
current server.

> that the client can't handle the CLID_INUSE error as I have described.

This requires that servers actually releases the clientid.  Even then, it
means that booting the client will take an extra lease period every time
the IP has changed.

I'm still not convinced that the current way of doing SETCLIENTID is
optimal.  But, since we have much to do, I will stop complaining about it,
at least until 4.0 is finished :-)