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

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1194546

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
where:
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)
use-case.


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.