Subject: [nfsv4] cancelling READW_LT/WRITEW_LT locks

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 5 Dec 2005 12:38:23 -0500

When a process waiting for a file lock gets an interrupt, we'd like to
be able to return without waiting for the lock to get granted.  We can't
just keep retrying the lock after returning EINTR, but we also can't
just forget about the lock, because then other clients may block for up
to a lease period waiting for a nonexistant file lock.

So we need a way to cancel a READW_LT or WRITEW_LT lock.

It seems reasonable to me to assume that READ_LT or WRITE_LT would
accomplish this; the server could take a nonblocking request with the
same lockowner and so on as an indication that the client was no longer
waiting.  The client could make the nonblocking request synchronously
and then return success or -EINTR to the processes depending on whether
the request is granted or not, and (in the -EINTR case) forget about the
lock.

The rfc doesn't address this problem, though.  What do other
implementations do?

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.

--b.

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 5 Dec 2005 16:06:42 -0500

> where part of the range on the blocking lock downgraded an exclusive

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.

--b.