[Gluster-devel] New locking strategy

[Anand Avati]

On Tue, Apr 3, 2012 at 6:20 AM, Xavier Hernandez <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)


> - lk locks may be mandatory or advisory.
>

mandatory mode is not tested for a very long time.


> - 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)


> (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

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