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

From: [email-masked]
Date: Thu, 2 Feb 2006 07:50:57 -0500

Today our server treats blocking locks as non blocking.

My plan for the near future is to treat blocking locks as NLM blocking locks
(locks for NFSv3), with a parameter to define the maximum latency in the
pending queue.
So, when a blocking lock request is received, if it cannot be granted, it
will be queued in the pending list, so that blocking requests are granted in
their arrival order.

Counter to NLM (which uses a callback), the reply isn't sent to the client
until:
- the lock can be granted -> reply OK
- the max latency in pending queue is reached -> reply DENIED
So there is ** no ambiguity **
Before the blocking lock is granted, it isn't. After it is granted or
denied, it is granted or denied.

This way we'll avoid the ambiguous cases evoked here. Here the server must
somewhat remind the blocked request that will downgrade the exclusive locks
because the client is supposed to do retries, and because the server must be
fair to this client, so, if an I/O from another client arises, the exclusive
locks are "in the process of" being shared locks... Well, I dislike this
implementation proposed by the RFC.

The idea of blocking the reply for a given amount of time is from SMB
protocol.
If there is some agreement for this implementation, it may be desirable in
version 4.1 to add a field in LOCK4args, so that the client can specify the
maximum amount of time he wants to wait for the lock reply.

Here is an extract from the SNIA specification "CIFS Technical reference
Revision 1.0":
"4.2.6. LOCKING_ANDX: Lock or Unlock Byte Ranges
Timeout is the maximum amount of time to wait for the byte range(s)
specified to become unlocked. A timeout value of 0 indicates that the server
should fail immediately if any lock range specified is locked. A timeout
value of -1 indicates that the server should wait as long as it takes for
each byte range specified to become unlocked so that it may be again locked
by this protocol.
Any other value of smb_timeout specifies the maximum number of milliseconds
to wait for all lock range(s) specified to become available."

Jean-Louis.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of J. Bruce Fields
> Sent: Tuesday, January 31, 2006 23:58
> To: [email-masked]
> Subject: Re: [nfsv4] Re: cancelling READW_LT/WRITEW_LT locks
> 
> On Tue, Jan 31, 2006 at 04:26:12PM -0600, Spencer Shepler wrote:
> > 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).
> 
> 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.
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 2 Feb 2006 18:56:37 -0600

If the server is going to delay response because of a conflicting lock,
I hope that the delay is measureed in a very small number of seconds so
as to avoid confusion between a non-responsive server or lost request
and a lock request that is just slow to see a response.

Spencer