Question about operations between SAL <-> FSAL for locking
Hello, I'm trying to integrate a FS supporting async lock (can run callback when a lock is granted) as ganesha FSAL. For the moment I do not make any upcalls to FSAL and the lock still work. I wonder how it can work? may be SAL handles that itself, does it have an internal lock queue and tries/retries the waiting lock by making lock calls again frequently to the FSAL to know when it can grant the lock? Can somebody shed some light on that? And if it is the case, I imagine that making the grant_lock upcall will increase the performance? Or there are even more benefits? Thank you Viet
On 06/15/2018 06:39 AM, Tuan Viet Nguyen wrote:
Hello,
I'm trying to integrate a FS supporting async lock (can run callback when a lock is granted) as ganesha FSAL. For the moment I do not make any upcalls to FSAL and the lock still work. I wonder how it can work? may be SAL handles that itself, does it have an internal lock queue and tries/retries the waiting lock by making lock calls again frequently to the FSAL to know when it can grant the lock?
Can somebody shed some light on that? And if it is the case, I imagine that making the grant_lock upcall will increase the performance? Or there are even more benefits?
Thank you Viet
So, SAL won't grant locks itself, it always calls lock_op2() in the FSAL to grant the lock. However, if there is a blocking lock, and the FSAL doesn't support async locks, then it will keep track of the lock itself, and whenever a lock is released, it will check to see if any blocked locks are now unblocked, and if so call lock_op2() to grant those locks. What does your FSAL set for fso_lock_support_async_block? What does your lock_op2() return for a normal lock attempt? Daniel
I set fso_lock_support_async_block = true, does it mean that disables the fact that SAL does not keep track of the lock itself and does not check blocked lock anymore? The lock_op2() returns ERR_FSAL_NO_ERROR if success, ERR_FSAL_LOCKED if the lock is already locked by another but for the moment I do not make any upcall at all. I have a test with blocking lock and it works, and I'm wondering & trying to figure out if the upcall is necessary. Do you have some advice? Thank you
On 06/15/2018 10:09 AM, ntvietvn@gmail.com wrote:
I set fso_lock_support_async_block = true, does it mean that disables the fact that SAL does not keep track of the lock itself and does not check blocked lock anymore?
The lock_op2() returns ERR_FSAL_NO_ERROR if success, ERR_FSAL_LOCKED if the lock is already locked by another but for the moment I do not make any upcall at all. I have a test with blocking lock and it works, and I'm wondering & trying to figure out if the upcall is necessary.
Do you have some advice?
Thank you _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
if fso_lock_support_async_block = true, then SAL will always call into the FSAL, even if it's already found a conflicting lock, and will not check for the blocking lock to be released. Instead, it will expect an up-call into the FSAL to grant the newly unblocked lock. If, however, that is false, then Ganesha will check when locks are released to see if this lock is unblocked, and then will attempt to grant it. This takes more processing, since the list of blocked locks must be traversed for each unlock, but it provides functionality the FSAL lacks. Daniel
Thanks a lot for your clear reply. It means that with my config (true) i have to add a upcall. IIRC in an old post in the previous mailinglist archive, I've read that this upcall may need to be done in a separate thread because the processing is blocking, is it still true? Because I saw an async wrapper up_async_lock_grant() so that must do the job. Thank you
So, you have a couple of options. The thread that calls up_ops->lock_grant() will be used all the way through to sending the notification to the client, so it will do the actual network I/O, which can block. If you have a free thread to use, you can just do that, and it will be fine. Alternatively, in your FSAL, you can call up_async_lock_grant() instead, which will queue the up-call for a thread pool to handle in the background, freeing up your thread immediately. You can see how GPFS calls this, as an example. Daniel On 06/15/2018 11:13 AM, ntvietvn@gmail.com wrote:
Thanks a lot for your clear reply. It means that with my config (true) i have to add a upcall. IIRC in an old post in the previous mailinglist archive, I've read that this upcall may need to be done in a separate thread because the processing is blocking, is it still true? Because I saw an async wrapper up_async_lock_grant() so that must do the job.
Thank you _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
Great, i've just found fsal_up.c in GPFS calling that. Thanks On Fri, Jun 15, 2018 at 5:20 PM, Daniel Gryniewicz <dang@redhat.com> wrote:
So, you have a couple of options. The thread that calls up_ops->lock_grant() will be used all the way through to sending the notification to the client, so it will do the actual network I/O, which can block. If you have a free thread to use, you can just do that, and it will be fine.
Alternatively, in your FSAL, you can call up_async_lock_grant() instead, which will queue the up-call for a thread pool to handle in the background, freeing up your thread immediately. You can see how GPFS calls this, as an example.
Daniel
On 06/15/2018 11:13 AM, ntvietvn@gmail.com wrote:
Thanks a lot for your clear reply. It means that with my config (true) i have to add a upcall. IIRC in an old post in the previous mailinglist archive, I've read that this upcall may need to be done in a separate thread because the processing is blocking, is it still true? Because I saw an async wrapper up_async_lock_grant() so that must do the job.
Thank you _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
participants (3)
-
Daniel Gryniewicz -
ntvietvn＠gmail.com -
Tuan Viet Nguyen