[Gluster-devel] New locking strategy

[Xavier Hernandez]

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 <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
>
>
> _______________________________________________
> 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/3b3881ac/attachment-0003.html>