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