[Bugs] [Bug 1550896] New: No rollback of renames on succeeded subvols during failure
bugzilla at redhat.com
bugzilla at redhat.com
Fri Mar 2 08:27:14 UTC 2018
https://bugzilla.redhat.com/show_bug.cgi?id=1550896
Bug ID: 1550896
Summary: No rollback of renames on succeeded subvols during
failure
Product: Red Hat Gluster Storage
Version: 3.3
Component: distribute
Keywords: Triaged
Assignee: nbalacha at redhat.com
Reporter: rgowdapp at redhat.com
QA Contact: tdesala at redhat.com
CC: bugs at gluster.org, rhs-bugs at redhat.com,
storage-qa-internal at redhat.com
Depends On: 1412069
+++ This bug was initially created as a clone of Bug #1412069 +++
Description of problem:
As with dht, dirs are present on all subvolumes, renaming them is a compound
operation and thus a partial success + partial failure scenario is possible,
resulting in an inconsistent state. For purposes of reproduction, such a
scenario can easily be produced by stopping the volume, edit the volfile of a
certain subvolume to get at an "option read-only on" setting, and then restart
the volume. Thus those operations that are to make change on the affected
subvolume will fail with EROFS.
Version-Release number of selected component (if applicable):
How reproducible:
always
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--- Additional comment from Worker Ant on 2017-01-11 02:01:30 EST ---
REVIEW: http://review.gluster.org/15739 (feature/dht: undo partially successful
dir rename) posted (#7) for review on master by Raghavendra G
(rgowdapp at redhat.com)
--- Additional comment from Worker Ant on 2017-01-11 10:40:29 EST ---
COMMIT: http://review.gluster.org/15739 committed in master by Raghavendra G
(rgowdapp at redhat.com)
------
commit bb438d849a4a3941c1a9b525213f695f0a2c961b
Author: Csaba Henk <csaba at redhat.com>
Date: Thu Oct 27 07:30:48 2016 +0200
feature/dht: undo partially successful dir rename
As with dht, dirs are present on all subvolumes,
renaming them is a compound operation and thus a
partial success + partial failure scenario is
possible, resulting in an inconsistent state.
For purposes of reproduction, such a scenario can
easily be produced by stopping the volume, edit the
volfile of a certain subvolume to get at an
"option read-only on" setting, and then restart
the volume. Thus those operations that are to make change
on the affected subvolume will fail with EROFS.
To handle such scenarios, we introduce an in-memory cache
where we record the return values obtained from the
subvolumes. At the final stage of the dir rename operation
we check if it's a partial success/fail situation. If yes,
then we perform a reverse rename op on those subvolumes
where the operation succeeded.
Change-Id: I3d05f74f53932cb984a918d252a7309c1009a51d
BUG: 1412069
Signed-off-by: Raghavendra G <rgowdapp at redhat.com>
Reviewed-on: http://review.gluster.org/15739
NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
Smoke: Gluster Build System <jenkins at build.gluster.org>
CentOS-regression: Gluster Build System <jenkins at build.gluster.org>
Reviewed-by: N Balachandran <nbalacha at redhat.com>
--- Additional comment from Shyamsundar on 2017-03-06 12:43:33 EST ---
This bug is getting closed because a release has been made available that
should address the reported issue. In case the problem is still not fixed with
glusterfs-3.10.0, please open a new bug report.
glusterfs-3.10.0 has been announced on the Gluster mailinglists [1], packages
for several distributions should become available in the near future. Keep an
eye on the Gluster Users mailinglist [2] and the update infrastructure for your
distribution.
[1] http://lists.gluster.org/pipermail/gluster-users/2017-February/030119.html
[2] https://www.gluster.org/pipermail/gluster-users/
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1412069
[Bug 1412069] No rollback of renames on succeeded subvols during failure
--
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=d6IyRIO4mU&a=cc_unsubscribe
More information about the Bugs
mailing list