Re: (fwd) nfs hang on 2.6.24

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Feb 06, 2008 at 12:52:17PM -0500, Trond Myklebust wrote:
> 
> On Wed, 2008-02-06 at 12:23 -0500, J. Bruce Fields wrote:
> > On Wed, Feb 06, 2008 at 10:15:23AM -0500, Trond Myklebust wrote:
> > > 
> > > On Wed, 2008-02-06 at 10:07 -0500, J. Bruce Fields wrote:
> > > 
> > > > That went into 2.6.22:
> > > > 
> > > > 	21315edd4877b593d5bf.. "[PATCH] knfsd: nfsd4: demote "clientid
> > > > 	in use" printk to a dprintk"
> > > > 
> > > > It may suggest a problem if this is happening a lot, though, right?
> > > 
> > > The client should always be able to generate a new unique clientid if
> > > this happens.
> > 
> > And then the client may fail to reclaim its state on the next server
> > reboot, or mistakenly prevent some other client from reclaiming state,
> > since it's not recording the new clientid in stable storage.  So if it's
> > happening a lot then we I suppose we should figure out better ways to
> > generate client id's.
> 
> Huh?
> 
> If the server reboots, the client will try to reclaim state using the
> _same_ client identifier string.

Oh, right, I was confusing client and server reboot and assuming the
client would forget the uniquifier on server reboot.  That's obviously
wrong!  The client will forget its own uniquifier on client reboot, but
that's alright since it's happy enough just to let that old state time
out at that point.  So the only possible problem is suboptimal behavior
when the client reboot time is less than the lease time.

> Two clients should _not_ be able to generate the same clientid unless
> they're also sharing the same IP address and a number of other
> properties that we include in the client identifier.

Or unless two client implementations just happen to have clashing
clientid generation algorithms, but we hope that's unlikely.

(Except that older Linux clients were prone to produce the same
clientid, if I remember right.  But the more likely explanation may be
that these are the result of a single client destroying and then
creating state on the server within a lease period, and the server being
stubborn and refusing to let go of the old state (even though no opens
are associated with it any more) until the end of a lease period.  I
think that's a server bug.)

--b.