<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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>
</body>
</html>