Subject: Re: [nfsv4] Re: cancelling READW_LT/WRITEW_LT locks

From: Spencer Shepler <[email-masked]>
Date: Tue, 31 Jan 2006 16:26:12 -0600

On Mon, J. Bruce Fields wrote:
> On Mon, Dec 05, 2005 at 12:38:23PM -0500, bfields wrote:
> > Note that sending a LOCKU doesn't do what you want; consider the case
> > where part of the range on the blocking lock downgraded an exclusive
> > lock.
> 
> The more I think about it the more tricky corner cases there seem to be
> for the server.
> 
> What if a client sends a large blocking read lock that simultaneously
> coalesces and downgrades several discontiguous exclusive locks?  How is
> the server supposed to hold that kind of lock on the client's behalf
> without irreversibly downgrading some locks and then risking that the
> client doesn't retry within the lease period?
> 
> Probably there's some way to do it--maybe just identify the crazy cases
> and give up on fairness then--but I doubt the typical filesystem locking
> API makes this easy.
> 

THis one is for the archives given the elapsed time but...

The Solaris server treats both lock types the same (as Ric said the BSD
server does).

The Solaris client, upon receiving an interrupt of the thread driving
the LOCK request, will allow the thread of control to return.  It then
goes on to track the fact that the LOCK request was sent and ensure that
it is either retransmitted or reaped.  THe biggest concern it to
track the stateid transitions appropriately since the server may have
received and processed the LOCK request before the thread of control
had a chance to receive and process the response...

Client is responsible for tracking the requests and recovering them
in the context that makes sense for its operating environment.

Spencer

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 31 Jan 2006 17:58:02 -0500

> The Solaris server treats both lock types the same (as Ric said the BSD

Yeah, I think we're giving up on trying to implement the
rfc3530-suggested queueing for blocking locks on the linux server.  I
think we need cancel calls before that's going to be practical to
implement.

--b.