Subject: Re: [nfsv4] RECLAIM_COMPLETE operation

From: [email-masked]
Date: Thu, 12 Jan 2006 17:18:31 -0500 (EST)

[good stuff snipped, then Bruce wrote]
> I had some trouble understanding this situation, so here's my attempt to
> make the sequence of events more concrete:
> 
> 	Client A acquires two locks, x and y.
> 	The server reboots.
> 	Client A reclaims lock x.
> 	The server ends the grace period, and makes a record in stable
> 		storage indicating that client A successfully
> 		established some state.
> 	Client B gets a lock conflicting y' conflicting with y, and the
> 		server makes a record in stable storage indicating that
> 		client B also succesfully established some state.
> 	The server reboots again.

[David Robinson wrote]
> But how can client A know that it is a bug or not? The client knows

I think Bruce was referring to the fact that for correct behaviour, an
NFSv4.0 client can only reclaim locks that it already successfully reclaimed,
after it sees another reboot of the server. (ie. Since it didn't reclaim
'y' before the second reboot, it knows that it can't safely reclaim 'y'
again.)

A "not so correct" client A would attempt to reclaim 'x' and 'y' after
the second server reboot.
(He notes, I believe correctly, that this is a client side implementation
 bug.)

The nice thing about RECOVERY_COMPLETE is that it allows the server to
correctly deal with a "not so correct" client instead of trusting the
clients to get it right.

Imho RECOVERY_COMPLETE is a good addition to the protocol. I think it is
also important that NFSv4.0 clients only reclaim locks they already reclaimed
successfully if they detect a server reboot while they are doing reclaim
against it.

rick

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