Re: [nfsv4] "Courtesy locks"

[Trond Myklebust <[e-mail]>]

On Sun, 2010-09-12 at 23:22 -0400, Rick Macklem wrote:
> > On Sun, 2010-09-12 at 12:21 -0400, [e-mail] wrote:
> > C) We try to send a RENEW. If that fails, we try to send a SETCLIENTID
> > that uses the same clientid and verifier as when we originally mounted
> > the filesystem.
> > After that, we try to replay all OPEN and LOCK calls.
> 
> Doesn't expired imply a conflicting lock could have been issued and
> then released by now. ie. It doesn't seem safe to re-acquire a byte
> range lock. (My client re-acquires Opens because they are all DENY_NONE,
> so my client doesn't care about Opens with DENY_xxx, where xxx is not NONE.)

We don't ever use deny modes in Linux.

> > 
> > > C2) If you didn't answer (a) to (C1), are there any assumptions
> > >     (of the sort mentioned in (S3) to (S6)) whose violation would
> > >     cause problems?
> > 
> > In principle not. We are supposed to be able to recover all locks on a
> > per-open_stateid basis.
> > 
> > IOW: if an open stateid, lock stateid or delegation stateid returns an
> > error, we should be able to replay just the OPEN+LOCK requests that
> > are
> > required to allow the application to proceed.
> > 
> > Note that we do not implement a SIGLOST feature in the case where the
> > application has lost a lock (although we probably should). We never
> > did
> > it for NFSv3, and since nobody has really requested it for NFSv4
> > either,
> > we have deferred implementing it there too.
> 
> So you are saying apps. might believe that they still hold a byte
> range lock, even if another client might have acquired/released a
> conflicting lock while it was network partitioned?

Yes. What I said above is that there is no mechanism in Linux (or POSIX
for that matter) for notifying apps that they have lost their locks.
Implementing SIGLOST might be one way to do so, but requires apps to be
rewritten to make use of it.

Trond