[Bugs] [Bug 1194546] Write behind returns success for a write irrespective of a conflicting lock held by another application

bugzilla at redhat.com bugzilla at redhat.com
Mon Apr 22 21:51:49 UTC 2019


Raghavendra Talur <rtalur at redhat.com> changed:

           What    |Removed                     |Added
              Flags|needinfo?(rtalur at redhat.com |needinfo?(anoopcs at redhat.co
                   |)                           |m)

--- Comment #7 from Raghavendra Talur <rtalur at redhat.com> ---
The patch posted(http://review.gluster.org/10350) for review handles the case
If both process A and B are on the same Gluster client machine, then it ensures
write-behind orders write and lock requests from both the processes in the
right order.

On review, Raghavendra G commented with the following example and review:
A write w1 is done and is cached in write-behind.
A mandatory lock is held by same thread which conflicts with w1 (Is that even a
valid case? If not, probably we don't need this patch at all). This mandatory
lock goes through write-behind and locks xlator grants this lock.
Now write-behind flushes w1 and posix-locks fails w1 as a conflicting mandatory
lock is held.
But now that I think of it, it seems like an invalid (exotic at its best)

Anoop/Raghavendra G,

>From mandatory locking and write-behind perspective, is it still an exotic
case? If so, we can close this bug.

You are receiving this mail because:
You are on the CC list for the bug.

More information about the Bugs mailing list