+++ This bug was initially created as a clone of Bug #1310171 +++ Description of problem: glusterfs user Mat Clayton told me on IRC that sometimes `ls -l of /mount/filename` on an arbiter volume reported zero bytes despite all bricks being up and the actual data file on the non-arbiter bricks being 120 Meg. Version-Release number of selected component (if applicable): v3.7.8 How reproducible: Sometimes the value is right and other times it is zero.
REVIEW: http://review.gluster.org/13582 (afr: do not set arbiter as a readable subvol in inode context) posted (#1) for review on release-3.7 by Ravishankar N (ravishankar)
COMMIT: http://review.gluster.org/13582 committed in release-3.7 by Pranith Kumar Karampuri (pkarampu) ------ commit ad0b1253b9d74797620c493184818685c024f17c Author: Ravishankar N <ravishankar> Date: Mon Feb 29 05:16:50 2016 +0000 afr: do not set arbiter as a readable subvol in inode context Backport-of: http://review.gluster.org/#/c/13539/ Problem: If afr_lookup_done() or afr_read_subvol_select_by_policy() chooses the arbiter brick to serve the stat() data, file size will be reported as zero from the mount, despite other data bricks being available. This can break programs like tar which use the stat info to decide how much to read. Fix: In the inode-context, mark arbiter as a non-readable subvol for both data and metadata. It it to be noted that by making this fix, we are *not* going to serve metadata FOPS anymore from the arbiter brick despite the brick storing the metadata. It makes sense to do this because the ever increasing over-loaded FOPs (getxattr returning stat data etc.) and compound FOPS in gluster will otherwise make it difficult to add checks in code to handle corner cases. Change-Id: Ic60b25d77fd05e0897481b7fcb3716d4f2101001 BUG: 1313921 Signed-off-by: Ravishankar N <ravishankar> Reported-by: Mat Clayton <mat> Reviewed-on: http://review.gluster.org/13582 Smoke: Gluster Build System <jenkins.com> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.com> Reviewed-by: Pranith Kumar Karampuri <pkarampu>
REVIEW: http://review.gluster.org/13609 (afr: do not set arbiter as a readable subvol in inode context) posted (#1) for review on release-3.7 by Pranith Kumar Karampuri (pkarampu)
REVIEW: http://review.gluster.org/13609 (afr: do not set arbiter as a readable subvol in inode context) posted (#2) for review on release-3.7 by Ravishankar N (ravishankar)
REVIEW: http://review.gluster.org/13609 (afr: do not set arbiter as a readable subvol in inode context) posted (#3) for review on release-3.7 by Pranith Kumar Karampuri (pkarampu)
REVIEW: http://review.gluster.org/13609 (afr: do not set arbiter as a readable subvol in inode context) posted (#4) for review on release-3.7 by Pranith Kumar Karampuri (pkarampu)
COMMIT: http://review.gluster.org/13609 committed in release-3.7 by Pranith Kumar Karampuri (pkarampu) ------ commit 10e091508ca6e5af815fce612be48287d354a01b Author: Ravishankar N <ravishankar> Date: Mon Feb 29 05:16:50 2016 +0000 afr: do not set arbiter as a readable subvol in inode context Problem: If afr_lookup_done() or afr_read_subvol_select_by_policy() chooses the arbiter brick to serve the stat() data, file size will be reported as zero from the mount, despite other data bricks being available. This can break programs like tar which use the stat info to decide how much to read. Fix: In the inode-context, mark arbiter as a non-readable subvol for both data and metadata. It it to be noted that by making this fix, we are *not* going to serve metadata FOPS anymore from the arbiter brick despite the brick storing the metadata. It makes sense to do this because the ever increasing over-loaded FOPs (getxattr returning stat data etc.) and compound FOPS in gluster will otherwise make it difficult to add checks in code to handle corner cases. >Change-Id: Ic60b25d77fd05e0897481b7fcb3716d4f2101001 >BUG: 1310171 >Signed-off-by: Ravishankar N <ravishankar> >Reported-by: Mat Clayton <mat> >Reviewed-on: http://review.gluster.org/13539 >Reviewed-by: Anuradha Talur <atalur> >Reviewed-by: Krutika Dhananjay <kdhananj> >Smoke: Gluster Build System <jenkins.com> >NetBSD-regression: NetBSD Build System <jenkins.org> >CentOS-regression: Gluster Build System <jenkins.com> >Reviewed-by: Jeff Darcy <jdarcy> BUG: 1313921 Change-Id: I07fc08d633ca2af48f7354454bc2ab75cedb850a Signed-off-by: Ravishankar N <ravishankar> Reviewed-on: http://review.gluster.org/13609 Reviewed-by: Pranith Kumar Karampuri <pkarampu> Tested-by: Pranith Kumar Karampuri <pkarampu> Smoke: Gluster Build System <jenkins.com> CentOS-regression: Gluster Build System <jenkins.com> NetBSD-regression: NetBSD Build System <jenkins.org>
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.7.9, please open a new bug report. glusterfs-3.7.9 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://www.gluster.org/pipermail/gluster-users/2016-March/025922.html [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user