[Gluster-devel] New locking strategy

[Xavier Hernandez]

On 04/03/2012 04:53 PM, Anand Avati wrote:
>
>
> On Tue, Apr 3, 2012 at 6:20 AM, Xavier Hernandez 
> <xhernandez at datalab.es <mailto:xhernandez at datalab.es>> wrote:
>
>     Hello developers,
>
>     I'm currently trying to implement a new method for managing inode
>     and entry modifications that will be faster (I hope) than the
>     current method for the most common cases. To do so I need to know
>     exactly how the locking mechanism works. I have been browsing the
>     source code and doing some tests, and I would like to be sure that
>     I have understood it correctly before continuing.
>
>     All information is based on latest qa releases from 3.3 branch.
>
>     My understanding is this:
>
>     - There are three locking fops: lk, inodelk and entrylk.
>     - Client application locks created using fcntl() are received by
>     the translators as lk requests.
>     - All other functionalities of lk fop are not currently used by
>     any translator (I mean F_RESLK_LCK, F_RESLK_LCKW, F_RESLK_UNLCK
>     and F_GETLK_FD).
>     - inodelk and entrlylk are only used by AFR to lock inodes or
>     directory entries before modification.
>     - Translators don't generate lk requests internally.
>     - Client application requests cannot directly generate an inodelk
>     or entrylk requests.
>
>
> Correct so far.
>
>     - inodelk and entrylk locks are always mandatory.
>
>
> inodelk and entrylk are always advisory. Never mandatory (at least so far)
Sorry, I was thinking one thing and said another. Never mind, it's as I 
expected: no request will be blocked by any of these locks (except 
themselves)

>     - lk locks may be mandatory or advisory.
>
>
> mandatory mode is not tested for a very long time.
Ok, I won't waste much time on mandatory locks.

>     - lk and inodelk are independent from each other, meaning that a
>     lock using lk will not be visible to inodelk and will not block
>     it. inodelk won't block lk requests neither.
>     - User requests can only be blocked by lk created locks
>
>
> Correct, and only if mandatory locks are enabled (which isn't tested 
> right now)
Ok.
>
>     (if a write request from user is allowed to pass without using
>     inodelk, it won't be blocked by a previous inodelk).
>
>
> inodelks are never mandatory, so the question does not apply
Ok.

Thank you very much

Xavi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120403/45302d70/attachment-0003.html>