[Gluster-devel] New locking strategy

[Anand Avati]

That is correct!

On Tue, Apr 3, 2012 at 8:46 AM, Xavier Hernandez <xhernandez at datalab.es>wrote:

>  Another question that I forgot...
>
> inodelk and entrylk locks exists inside a domain. This means that, for
> example, each inodelk lock is only visible inside its own domain and won't
> block other inodelk requests from other domains, even if they refer to the
> same region of the file. Is this correct ?
>
> Xavi
>
>
> On 04/03/2012 05:20 PM, Xavier Hernandez wrote:
>
> 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>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
>
>
> _______________________________________________
> Gluster-devel mailing listGluster-devel at nongnu.orghttps://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120403/1b74d154/attachment-0003.html>