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
