12:24 p.m.
Yes, I forgot to mention that it was in case of STATE_NFSV4_BLOCKING
specifically
Ganesha doesn't have the infrastructure to implement V4.0 or V4.1 blocking locks.
4.x blocking locks are sort of optional
In 4.0, the client periodically retries blocking locks.
In 4.1, I the client still periodically retries, but the server also has the option of a
call back, which just tells the client to retry now.
In either case, a server that attempts to support 4.x blocking locks would keep track of
the blocking lock requests in an ordered list (to preserve fairness) and then when the
lock becomes available, the server would give preference to the client first on the list
being granted the lock when it retries, in the meantime, denying the lock to other clients
that retry.
There is some complex logic to maintain all this.
When (if) we implement this logic, for 4.1 we would probably issue a blocking lock request
to the FSAL (maybe just for the first client, maybe for all - and let the FSAL or its
underlying filesystem resolve the fairness). When the FSAL grants the lock, we would then
"hold" the lock for some period of time to give the client a chance to retry and
solidify the granted lock. If the client is 4.1 and the backchannel is up, we would send a
CB_NOTIFY_LOCK. If the client did not retry in time, we would release the lock (and
discard the client's blocking lock notification), and then either pick the next
blocked lock (or we have sent all to the FSAL, so then the next would automatically be
granted). We would also need to monitor the conditions for "cancelling" the
blocked lock.
See Section 9.6. Blocking Locks on p. 190 of RFC 5661 for the 4.1 details.
Frank