> 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