[Gluster-devel] Question about EC locking

[jayakrishnan mm]

Thanks Xavier, for making it clear.
Regards
JK

On Dec 13, 2016 3:52 PM, "Xavier Hernandez" <xhernandez at datalab.es> wrote:

Hi JK,


On 12/13/2016 08:34 AM, jayakrishnan mm wrote:

> Dear Xavi,
>
> How do I test  the locks, for example locks  for write fop. I have two
> clients(independent), both  are  trying to write to same file.
>
>
> 1. According to my understanding, both  can successfully write  if the
> offsets don't overlap . I mean, the WRITE FOP  takes a chunk lock on the
> file . As
> long as the clients don't try  to write to the same chunk, it should be
> OK. If no locks  present, it can lead to inconsistency.
>

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.



>
> 2.  Different FOPs can always run simultaneously. (Example  WRITE  and
> READ FOPs, or  two READ FOPs).
>

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.



> 3. WRITE & some metadata FOP (like setattr)  together . Cannot happen
> together with locks , even though chances  are very low.
>

As in 2, if there's any possible interference, the appropriate locks will
be taken.

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.

Xavi


> Pls. clarify.
>
> Best regards
> JK
>
>
>
> On Wed, Nov 30, 2016 at 5:49 PM, jayakrishnan mm
> <jayakrishnan.mm at gmail.com <mailto:jayakrishnan.mm at gmail.com>> wrote:
>
>     Hi Xavier,
>
>     Thank you very much for your explanation. This helped  me to
>     understand  more  about  locking in EC.
>
>     Best Regards
>     JK
>
>
>     On Mon, Nov 28, 2016 at 4:17 PM, Xavier Hernandez
>     <xhernandez at datalab.es <mailto:xhernandez at datalab.es>> wrote:
>
>         Hi,
>
>         On 11/28/2016 02:59 AM, jayakrishnan mm wrote:
>
>             Hi Xavier,
>
>             Notice  that EC xlator uses blocking locks. Any specific
>             reason for this?
>
>
>         In a distributed filesystem like gluster a synchronization
>         mechanism is a must to avoid data corruption.
>
>
>             Do you think this will  affect the  performance ?
>
>
>         Of course the need for locks has a performance impact, and we
>         cannot avoid them to guarantee data integrity. However some
>         optimizations have been applied, specially the eager locking
>         which allows a lock to be reused without unlocking/locking again.
>
>
>             (In comparison AFR  first tries  non blocking locks  and if not
>             successful, tries blocking locks then)
>
>
>         EC also tries a non-blocking lock first.
>
>
>             Also, why two locks  are  needed  per FOP ? One for normal
>             I/O and
>             another for self healing?
>
>
>         The only fop that currently needs two locks is 'rename', and
>         only when source and destination directories are different. All
>         other fops only take one lock at most.
>
>         Best regards,
>
>         Xavi
>
>
>             Best regards
>             JK
>
>
>             _______________________________________________
>             Gluster-devel mailing list
>             Gluster-devel at gluster.org <mailto:Gluster-devel at gluster.org>
>             http://www.gluster.org/mailman/listinfo/gluster-devel
>             <http://www.gluster.org/mailman/listinfo/gluster-devel>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20161214/ae6e69c6/attachment-0001.html>