state_lock detects conflict independetly of the async lock opt
Hello, While reading the state_lock() fct i see this comment /* We have already returned if: * + we have found an identical blocking lock * + we have found an entirely overlapping lock with the same lock owner * + this was not a supported blocking lock and we found a conflict * * So at this point, we are either going to do one of the following (all * descriptions below assume no problems occur): * * (1) FSAL supports async blocking locks, we know there is a conflict, ( and this is a supported blocking lock request * * Make FSAL_OP_LOCKB call anyway, we will rely on FSAL to grant * blocking locks. We will return the conflict we know about rather * than what the FSAL returns. Insert blocking lock into queue. It seems that it is contradictory to the code above the comment which is in case of conflict lock, the fct returns immediately and does not make any call to FSAL, even if it supports async blocking lock. Can you clarify this point? Thank you
The code looks fine, except that it appears to be missing check for STATE_NFSV4_BLOCKING. Frank? Daniel On 06/19/2018 12:10 PM, ntvietvn@gmail.com wrote:
Hello,
While reading the state_lock() fct i see this comment
/* We have already returned if: * + we have found an identical blocking lock * + we have found an entirely overlapping lock with the same lock owner * + this was not a supported blocking lock and we found a conflict * * So at this point, we are either going to do one of the following (all * descriptions below assume no problems occur): * * (1) FSAL supports async blocking locks, we know there is a conflict, ( and this is a supported blocking lock request * * Make FSAL_OP_LOCKB call anyway, we will rely on FSAL to grant * blocking locks. We will return the conflict we know about rather * than what the FSAL returns. Insert blocking lock into queue.
It seems that it is contradictory to the code above the comment which is in case of conflict lock, the fct returns immediately and does not make any call to FSAL, even if it supports async blocking lock. Can you clarify this point?
Thank you _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
Yes, I forgot to mention that it was in case of STATE_NFSV4_BLOCKING specifically Thanks
On 06/19/2018 12:51 PM, ntvietvn@gmail.com wrote:
Yes, I forgot to mention that it was in case of STATE_NFSV4_BLOCKING specifically
Thanks _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
https://review.gerrithub.io/#/c/ffilz/nfs-ganesha/+/416029 I'm really surprised that pynfs doesn't catch this... Daniel
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
Thank you Frank for that clear explanation. On Tue, Jun 19, 2018 at 7:24 PM, Frank Filz <ffilzlnx@mindspring.com> wrote:
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
participants (4)
-
Daniel Gryniewicz -
Frank Filz -
ntvietvn＠gmail.com -
Tuan Viet Nguyen