Re: New locking strategy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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@xxxxxxxxxx
https://lists.nongnu.org/mailman/listinfo/gluster-devel

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux