<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Another question that I forgot...<br>
<br>
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 ?<br>
<br>
Xavi<br>
<br>
On 04/03/2012 05:20 PM, Xavier Hernandez wrote:
<blockquote cite="mid:4F7B155B.5040201@datalab.es" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
On 04/03/2012 04:53 PM, Anand Avati wrote:
<blockquote
cite="mid:CAFboF2ydQkcEZ-j7Q=9649hbCJx2i1KrVfWhgxU0B8mOT5pXuQ@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On Tue, Apr 3, 2012 at 6:20 AM, Xavier
Hernandez <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:xhernandez@datalab.es">xhernandez@datalab.es</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> Hello
developers,<br>
<br>
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.<br>
<br>
All information is based on latest qa releases from 3.3
branch.<br>
<br>
My understanding is this:<br>
<br>
- There are three locking fops: lk, inodelk and entrylk.<br>
- Client application locks created using fcntl() are
received by the translators as lk requests.<br>
- 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).<br>
- inodelk and entrlylk are only used by AFR to lock inodes
or directory entries before modification.<br>
- Translators don't generate lk requests internally.<br>
- Client application requests cannot directly generate an
inodelk or entrylk requests.<br>
</blockquote>
<div><br>
</div>
<div>Correct so far.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> - inodelk
and entrylk locks are always mandatory.<br>
</blockquote>
<div><br>
</div>
<div>inodelk and entrylk are always advisory. Never mandatory
(at least so far)</div>
</div>
</blockquote>
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)<br>
<br>
<blockquote
cite="mid:CAFboF2ydQkcEZ-j7Q=9649hbCJx2i1KrVfWhgxU0B8mOT5pXuQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> - lk
locks may be mandatory or advisory.<br>
</blockquote>
<div><br>
</div>
<div>mandatory mode is not tested for a very long time.</div>
</div>
</blockquote>
Ok, I won't waste much time on mandatory locks.<br>
<br>
<blockquote
cite="mid:CAFboF2ydQkcEZ-j7Q=9649hbCJx2i1KrVfWhgxU0B8mOT5pXuQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> - 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.<br>
- User requests can only be blocked by lk created locks</blockquote>
<div><br>
</div>
<div>Correct, and only if mandatory locks are enabled (which
isn't tested right now)</div>
</div>
</blockquote>
Ok.<br>
<blockquote
cite="mid:CAFboF2ydQkcEZ-j7Q=9649hbCJx2i1KrVfWhgxU0B8mOT5pXuQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> (if a
write request from user is allowed to pass without using
inodelk, it won't be blocked by a previous inodelk).<br>
<br>
</blockquote>
<div><br>
</div>
<div>inodelks are never mandatory, so the question does not
apply</div>
</div>
</blockquote>
Ok.<br>
<br>
Thank you very much<br>
<br>
Xavi<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gluster-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a>
<a class="moz-txt-link-freetext" href="https://lists.nongnu.org/mailman/listinfo/gluster-devel">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a>
</pre>
</blockquote>
</body>
</html>