Re: Question about EC locking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


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

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

Pls. clarify.

Best regards
JK



On Wed, Nov 30, 2016 at 5:49 PM, jayakrishnan mm <jayakrishnan.mm@xxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel




_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux