[PATCH 1/8] lockd: nfsd4: use same grace period for lockd and nfsd4

[J. Bruce Fields]

On Thu, Jun 21, 2007 at 02:08:37PM +1000, Neil Brown wrote:
> On Wednesday June 20, bfields at fieldses.org wrote:
> > Currently the lockd and nfsd enforce grace periods of different lengths.
> > This may cause problems when we reboot a server with both v2/v3 and v4
> > clients.  For example, if the lockd grace period is shorter (as is likely
> > the case), then a v3 client might acquire a new lock that conflicts with a
> > lock already held (but not yet reclaimed) by a v4 client.
> 
> And if a local application, or an SMB client takes a lock...  It feels
> like we want the grace period to be managed at the VFS level, but I
> guess that is a question for another day.

Yah.  Even if you know about the problem, how do you design the startup
sequence to avoid it?  You'd need some way to find out when the grace
period is over.

There's a similar case when handling migration or failover of nfs
clients on a cluster filesystem--if you're depending on ordinary nfs
reboot recovery to allow the client to recover locks on the new node,
how do you block other applications (possibly on other nodes) from
grabbing locks while this is going on?

> > -		grace_period = ((nlm_grace_period + nlm_timeout - 1)
> > +		return ((nlm_grace_period + nlm_timeout - 1)
> >  				/ nlm_timeout) * nlm_timeout * HZ;
> 
>  return roundup(nlm_grace_period, nlm_timeout) * HZ;

Oh, neat, I'd missed roundup().

> For the rest:
>   It is clearly an improvement, but it is still all rather clunky,
>   isn't it ?

Definitely.

>   lockd and nfsd4 calculate the endtime of the period independently,
>   and have separate flags for recording whether we are currently in
>   the grace period.
>   Those, at least, could be in variables exported from lockd.
>   nfsd needs to perform an action before the grace period is allowed
>   to end, so maybe we need a 'register_notifier' interface so that
>   when nfsd or lockd notice that the grace period is up, the notifiers
>   get called, and nfsd does it's cleanup.
> 
> Anyway, that can be work for another day, and you say you have more
> plans for that code, so that is good.

Right.  If someone's offended and wants to write a better interim
solution, I won't object.

But the NFSv4 server has some unnecessarily delicate assumptions about
the end of the grace period, and with those fixed it should be easier to
do the obvious thing.

--b.