<div dir="ltr">Hi Xavier,<div>I went through the source code. Some questions remain.</div><div><br></div><div>1. If two clients try to write to same file, it should succeed, even if they overlap. (Locks should ensure it happens in sequence, in the bricks).</div><div>from the source code </div><div><div> lock->flock.l_type = F_WRLCK;</div><div> lock->flock.l_whence = SEEK_SET;</div></div><div><br></div><div><div> fop->flock.l_len += ec_adjust_offset(fop->xl->private,</div><div> &fop->flock.l_start, 1);</div><div> fop->flock.l_len = ec_adjust_size(fop->xl->private,</div><div> fop->flock.l_len, 1);</div></div><div>if flock.l_len is 0, the entire file is locked for writing</div><div><br></div><div>In my test case with 2 clients, I always get flock.l_len as 0. But still I am able to write to the same file from both clients at the same time.</div><div><br></div><div>If it is acquiring lock chunk by chunk, why I am getting l_len =0 always ? Why I am not getting the actual write size and offset f(for flock.l_len & flock.l_start respectively) for each write FOP ?</div><div>(In afr , it is set to transaction.len transaction.start respectively, which in turn is write length & offset for the normal write case)</div><div><br></div><div>2. As per source code ,a full file lock is taken by the shd also.</div><div><br></div><div>ec_heal_inodelk(heal, F_WRLCK, 1, 0, 0);<br></div><div> which means offset=0 & size=0 in ec_heal_lock() function in ec-heal.c</div><div>flock.l_start = offset;<br></div><div>flock.l_len = size;<br></div><div>Does it mean , in a single file write cannot happen simultaneously with healing? </div><div><br></div><div>Correct me , if I am wrong.</div><div><br></div><div>Best Regards</div><div>JK</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 14, 2016 at 12:07 PM, jayakrishnan mm <span dir="ltr"><<a href="mailto:jayakrishnan.mm@gmail.com" target="_blank">jayakrishnan.mm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Thanks Xavier, for making it clear. <br>
Regards <br>
JK</p><div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br><div class="gmail_quote">On Dec 13, 2016 3:52 PM, "Xavier Hernandez" <<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>> wrote:<br type="attribution"><blockquote class="m_2850493010499036847quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi JK,<div class="m_2850493010499036847quoted-text"><br>
<br>
On 12/13/2016 08:34 AM, jayakrishnan mm wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear Xavi,<br>
<br>
How do I test the locks, for example locks for write fop. I have two<br>
clients(independent), both are trying to write to same file.<br>
<br>
<br>
1. According to my understanding, both can successfully write if the<br>
offsets don't overlap . I mean, the WRITE FOP takes a chunk lock on the<br>
file . As<br>
long as the clients don't try to write to the same chunk, it should be<br>
OK. If no locks present, it can lead to inconsistency.<br>
</blockquote>
<br></div>
With locks all writes will be fine as defined by posix (i.e. the final result will be equivalent to the sequential execution of both operations, though in an undefined order), even if they overlap. Without locks, there are chances that some bricks execute the operations in one order and the remaining bricks execute the same operations in the reverse order, causing data corruption.<div class="m_2850493010499036847quoted-text"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
2. Different FOPs can always run simultaneously. (Example WRITE and<br>
READ FOPs, or two READ FOPs).<br>
</blockquote>
<br></div>
All fops can be executed concurrently. If there's any chance that two operations could interfere, locks are taken in the appropriate places. For example, reads cannot be merged with overlapping writes. Otherwise they could return inconsistent data.<div class="m_2850493010499036847quoted-text"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. WRITE & some metadata FOP (like setattr) together . Cannot happen<br>
together with locks , even though chances are very low.<br>
</blockquote>
<br></div>
As in 2, if there's any possible interference, the appropriate locks will be taken.<br>
<br>
You can look at the code to see which locks are taken for each fop. See the corresponding ec_manager_<fop>() function, in the EC_STATE_LOCK switch case. There you will see calls to ec_lock_prepare_xxx() for each taken lock.<br>
<br>
Xavi<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_2850493010499036847quoted-text">
<br>
Pls. clarify.<br>
<br>
Best regards<br>
JK<br>
<br>
<br>
<br>
On Wed, Nov 30, 2016 at 5:49 PM, jayakrishnan mm<br></div><div class="m_2850493010499036847quoted-text">
<<a href="mailto:jayakrishnan.mm@gmail.com" target="_blank">jayakrishnan.mm@gmail.com</a> <mailto:<a href="mailto:jayakrishnan.mm@gmail.com" target="_blank">jayakrishnan.mm@gmail.<wbr>com</a>>> wrote:<br>
<br>
Hi Xavier,<br>
<br>
Thank you very much for your explanation. This helped me to<br>
understand more about locking in EC.<br>
<br>
Best Regards<br>
JK<br>
<br>
<br>
On Mon, Nov 28, 2016 at 4:17 PM, Xavier Hernandez<br></div><div class="m_2850493010499036847elided-text">
<<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a> <mailto:<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>><wbr>> wrote:<br>
<br>
Hi,<br>
<br>
On 11/28/2016 02:59 AM, jayakrishnan mm wrote:<br>
<br>
Hi Xavier,<br>
<br>
Notice that EC xlator uses blocking locks. Any specific<br>
reason for this?<br>
<br>
<br>
In a distributed filesystem like gluster a synchronization<br>
mechanism is a must to avoid data corruption.<br>
<br>
<br>
Do you think this will affect the performance ?<br>
<br>
<br>
Of course the need for locks has a performance impact, and we<br>
cannot avoid them to guarantee data integrity. However some<br>
optimizations have been applied, specially the eager locking<br>
which allows a lock to be reused without unlocking/locking again.<br>
<br>
<br>
(In comparison AFR first tries non blocking locks and if not<br>
successful, tries blocking locks then)<br>
<br>
<br>
EC also tries a non-blocking lock first.<br>
<br>
<br>
Also, why two locks are needed per FOP ? One for normal<br>
I/O and<br>
another for self healing?<br>
<br>
<br>
The only fop that currently needs two locks is 'rename', and<br>
only when source and destination directories are different. All<br>
other fops only take one lock at most.<br>
<br>
Best regards,<br>
<br>
Xavi<br>
<br>
<br>
Best regards<br>
JK<br>
<br>
<br>
______________________________<wbr>_________________<br>
Gluster-devel mailing list<br></div>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a> <mailto:<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.<wbr>org</a>><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman<wbr>/listinfo/gluster-devel</a><br>
<<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailma<wbr>n/listinfo/gluster-devel</a>><br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>