[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 G <rgowdapp at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|needinfo?(anoopcs at redhat.co |
                   |m)                          |
                   |needinfo?(rgowdapp at redhat.c |
                   |om)                         |



--- Comment #8 from Raghavendra G <rgowdapp at redhat.com> ---
(In reply to Raghavendra Talur from comment #7)
> 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.

What I missed above is when write and lock requests happen from two different
processes on same mount point (which the commit msg says). For that case, this
patch is still required.

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

No. I was wrong. This patch is required for multiple process scenario.

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