5:39 a.m.
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
8:23 a.m.
New subject: [Nfs-ganesha-devel] Re: Question about operations between SAL <-> FSAL for locking
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
9:09 a.m.
New subject: [Nfs-ganesha-devel] Re: Question about operations between SAL <-> FSAL for locking
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
10 a.m.
New subject: [Nfs-ganesha-devel] Re: Question about operations between SAL <-> FSAL for locking
On 06/15/2018 10:09 AM, ntvietvn(a)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(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)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
10:13 a.m.
New subject: [Nfs-ganesha-devel] Re: Question about operations between SAL <-> FSAL for locking
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
10:20 a.m.
New subject: [Nfs-ganesha-devel] Re: Question about operations between SAL <-> FSAL for locking
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(a)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(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
10:25 a.m.
New subject: [Nfs-ganesha-devel] Re: Question about operations between SAL <-> FSAL for locking
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(a)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(a)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(a)lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>
> _______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
2368
days inactive
2368
days old
6 comments
3 participants
participants (3)
-
Daniel Gryniewicz -
ntvietvn＠gmail.com -
Tuan Viet Nguyen