[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
Tue Apr 23 01:14:59 UTC 2019


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.

More information about the Bugs mailing list