+++ This bug was initially created as a clone of Bug #1662264 +++ Description of problem: In case of creating an entry, if a fop fails on any one of the data bricks, we mark the changelog on that entry on the brick which was successful. For thin arbiter volume before marking this changelog, we should check if the brick on which fop succeeded was the good brick or not. If the bricks was bad according to thin-arbiter file information, we should just continue with postop changelog process. If the brick was good, we should mark the new entry changelog and continuew with postop changelog. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: --- Additional comment from Worker Ant on 2018-12-27 09:19:25 UTC --- REVIEW: https://review.gluster.org/21933 (cluster/thin-arbiter: Consider thin-arbiter before marking new entry changelog) posted (#1) for review on master by Ashish Pandey --- Additional comment from Worker Ant on 2019-02-01 05:45:32 UTC --- REVIEW: https://review.gluster.org/21933 (cluster/thin-arbiter: Consider thin-arbiter before marking new entry changelog) merged (#6) on master by Amar Tumballi
REVIEW: https://review.gluster.org/22161 (cluster/thin-arbiter: Consider thin-arbiter before marking new entry changelog) merged (#4) on release-5 by Shyamsundar Ranganathan
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-5.5, please open a new bug report. glusterfs-5.5 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] https://lists.gluster.org/pipermail/announce/2019-March/000119.html [2] https://www.gluster.org/pipermail/gluster-users/