+++ This bug was initially created as a clone of Bug #1433838 +++ I am seeing a lot of messages in qe/customer logs where read_txn complains that file is possibly in split-brain because of no readable subvol being found, does inode refresh and then there is no split-brain message post the inode refresh. This means that a lookup was not issued on the indoe to populate 'readable' or it can mean one brick is source for data and the other for metadata, making readable to be zero (because readable=intersection of (data,metadata readable) since commit 7a1c1e290470149696. Since we anyway log actual split-brains post inode-refresh, move this message to DEBUG log level. --- Additional comment from Worker Ant on 2017-03-20 00:48:18 EDT --- REVIEW: https://review.gluster.org/16879 (afr: do not mention split-brain in log message in read_txn) posted (#3) for review on master by Ravishankar N (ravishankar) --- Additional comment from Worker Ant on 2017-03-20 05:39:30 EDT --- REVIEW: https://review.gluster.org/16879 (afr: do not mention split-brain in log message in read_txn) posted (#4) for review on master by Ravishankar N (ravishankar) --- Additional comment from Worker Ant on 2017-03-20 09:58:53 EDT --- COMMIT: https://review.gluster.org/16879 committed in master by Pranith Kumar Karampuri (pkarampu) ------ commit 71e023fcaab0058f32fedc7b6b702040fdd85f46 Author: Ravishankar N <ravishankar> Date: Sun Mar 19 22:42:33 2017 +0530 afr: do not mention split-brain in log message in read_txn I am seeing a lot of messages in qe/customer logs where read_txn complains that file is possibly in split-brain because of no readable subvol being found, does inode refresh and then there is no split-brain message post the inode refresh. This means that a lookup was not issued on the indoe to populate 'readable' or it can mean one brick is source for data and the other for metadata, making readable to be zero (because readable=intersection of (data,metadata readable) since commit 7a1c1e290470149696. Since we anyway log actual split-brains post inode-refresh, move this message to DEBUG log level. Change-Id: Idb88b8ea362515279dc9b246f06b6b646c6d8013 BUG: 1433838 Signed-off-by: Ravishankar N <ravishankar> Reviewed-on: https://review.gluster.org/16879 Reviewed-by: Pranith Kumar Karampuri <pkarampu> Tested-by: Pranith Kumar Karampuri <pkarampu> Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org>
REVIEW: https://review.gluster.org/16934 (afr: do not mention split-brain in log message in read_txn) posted (#1) for review on release-3.10 by Ravishankar N (ravishankar)
COMMIT: https://review.gluster.org/16934 committed in release-3.10 by Shyamsundar Ranganathan (srangana) ------ commit a25ea72ce662122318778c49a9366a9afd4902dc Author: Ravishankar N <ravishankar> Date: Sun Mar 19 22:42:33 2017 +0530 afr: do not mention split-brain in log message in read_txn I am seeing a lot of messages in qe/customer logs where read_txn complains that file is possibly in split-brain because of no readable subvol being found, does inode refresh and then there is no split-brain message post the inode refresh. This means that a lookup was not issued on the indoe to populate 'readable' or it can mean one brick is source for data and the other for metadata, making readable to be zero (because readable=intersection of (data,metadata readable) since commit 7a1c1e290470149696. Since we anyway log actual split-brains post inode-refresh, move this message to DEBUG log level. > Signed-off-by: Ravishankar N <ravishankar> > Reviewed-on: https://review.gluster.org/16879 > Reviewed-by: Pranith Kumar Karampuri <pkarampu> > Tested-by: Pranith Kumar Karampuri <pkarampu> > Smoke: Gluster Build System <jenkins.org> > NetBSD-regression: NetBSD Build System <jenkins.org> > CentOS-regression: Gluster Build System <jenkins.org> (cherry picked from commit 71e023fcaab0058f32fedc7b6b702040fdd85f46) Change-Id: Idb88b8ea362515279dc9b246f06b6b646c6d8013 BUG: 1434303 Reviewed-on: https://review.gluster.org/16934 Tested-by: Ravishankar N <ravishankar> Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Pranith Kumar Karampuri <pkarampu>
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.1, please open a new bug report. glusterfs-3.10.1 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-April/030494.html [2] https://www.gluster.org/pipermail/gluster-users/