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
<[email protected] <mailto:[email protected]>> 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
[email protected]
https://lists.nongnu.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/gluster-devel
