Re: [nfsv4] "Courtesy locks"

[Rick Macklem <[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.

Yep, the FreeBSD8 client doesn't either. Sorry for the confusion.
(ie. It always Opens with DENY_NONE.)

> 
> > >
> > > > 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.
> 
You could always, as the Governor of California might say:
"terminate them":-).

I haven't solved this for FreeBSD8 either. (It has no SIGLOST.) I
think what happens is:
- any further attempts at lokc ops fail because there isn't any
  open/lock state.
- I/O ops. fall back to using the special stateid of all 0s and
  succeed or fail at the whim of the server.

rick