Thanks Xavier, for making it clear.
Regards
JK
On Dec 13, 2016 3:52 PM, "Xavier Hernandez" <xhernandez@xxxxxxxxxx> wrote:
Hi JK,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.
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.
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.
2. Different FOPs can always run simultaneously. (Example WRITE and
READ FOPs, or two READ FOPs).
As in 2, if there's any possible interference, the appropriate locks will be taken.
3. WRITE & some metadata FOP (like setattr) together . Cannot happen
together with locks , even though chances are very low.
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@xxxxxxxxx <mailto:jayakrishnan.mm@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@xxxxxxxxxx <mailto:xhernandez@xxxxxxxxxx>Gluster-devel@xxxxxxxxxxx <mailto:Gluster-devel@gluster.> 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 listorg >
http://www.gluster.org/mailman/listinfo/gluster-devel
<http://www.gluster.org/mailman/listinfo/gluster-devel >
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
