[Bugs] [Bug 1603056] When reserve limits are reached, append on an existing file after truncate operation results to hang

[bugzilla at redhat.com]

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

Worker Ant <bugzilla-bot at gluster.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|POST                        |MODIFIED



--- Comment #3 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: https://review.gluster.org/20532 committed in release-4.1 by
"Shyamsundar Ranganathan" <srangana at redhat.com> with a commit message- afr:
switch lk_owner only when pre-op succeeds

Problem:
In a disk full scenario, we take a failure path in
afr_transaction_perform_fop()
and go to unlock phase. But we change the lk-owner before that, causing unlock
to fail. When mount issues another fop that takes locks on that file, it hangs.

Fix:
Change lk-owner only when we are about to perform the fop phase.
Also fix the same issue for arbiters when afr_txn_arbitrate_fop() fails the
fop.

Also removed the DISK_SPACE_CHECK_AND_GOTO in posix_xattrop. Otherwise truncate
to zero will fail pre-op phase with ENOSPC when the user is actually trying to
freee up space.

Change-Id: Ic4c8a596b4cdf4a7fc189bf00b561113cf114353
fixes: bz#1603056
Signed-off-by: Ravishankar N <ravishankar at redhat.com>
(cherry picked from commit ec0d7d77de3e4bd485a4fa2e53c9137e25c71ce7)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ErmFGhYcLg&a=cc_unsubscribe