Description of problem: Like fuse, its better to do an explicit lookup on the inodes linked via readdirp. Otherwise, post linkage directly fops will come and below xlators such as AFR, DHT will not be able to do their house keeping activities for the inode, which they would have done in lookup. So do an explicit lookup on those inodes linked via readdirp, before proceeding with the first fop on those inodes. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
COMMIT: http://review.gluster.org/11236 committed in master by Niels de Vos (ndevos) ------ commit c1a8ae20bd055227921d199b952582eca4104f67 Author: Raghavendra Bhat <raghavendra> Date: Fri Jun 12 15:12:05 2015 +0530 libgfapi: send explicit lookups on inodes linked in readdirp If the inode is linked via readdirp, then the consuners of gfapi which are using handles (got either in lookup or readdirp) might not send an explicit lookup on that object again (ex: NFS, samba, USS). If there is a replicate volume where the replicas of the object are not in sync, then readdirp followed by fops might lead data being served from the subvolume which is not in sync with latest data. And since lookup is needed to trigger self-heal on that object the consumers might keep getting wrong data until an explicit lookup is not done. Fuse handles this situation by sending an explicit lookup by itself (fuse xlator) on those inodes which are linked via readdirp, whenever a fop comes on that inode. The same procedure is done in gfapi as well to address this situation. Thanks to shyam(srangana) for valuable inputs Change-Id: I64f0591495dddc1dea7f8dc319f2558a7e342871 BUG: 1236009 Signed-off-by: Raghavendra Bhat <raghavendra> Reviewed-on: http://review.gluster.org/11236 Tested-by: NetBSD Build System <jenkins.org> Reviewed-by: Shyamsundar Ranganathan <srangana> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Niels de Vos <ndevos>
Fix for this BZ is already present in a GlusterFS release. You can find clone of this BZ, fixed in a GlusterFS release and closed. Hence closing this mainline BZ as well.
Re-opening for addressing the comment from kinsu in https://github.com/gluster/glusterfs/commit/c1a8ae20bd055227921d199b952582eca4104f67#commitcomment-17490144
REVIEW: http://review.gluster.org/14363 (core: correct the if-statment in inode_set_need_lookup()) posted (#1) for review on master by Niels de Vos (ndevos)
COMMIT: http://review.gluster.org/14363 committed in master by Vijay Bellur (vbellur) ------ commit eb705e090a4748efd18279ad920b2db295f2075a Author: Niels de Vos <ndevos> Date: Mon May 16 19:53:44 2016 +0200 core: correct the if-statment in inode_set_need_lookup() There does not seem to be an ill side-effect from the incorrect if-statement. But we should really stick to the same checks we do everywhere. BUG: 1236009 Change-Id: If2b787287ac0d87712840b15b8c914e3dc5ffcde Reported-by: kinsu <vpolakis> Signed-off-by: Niels de Vos <ndevos> Reviewed-on: http://review.gluster.org/14363 Smoke: Gluster Build System <jenkins.com> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.com> Reviewed-by: Vijay Bellur <vbellur>
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.8.0, please open a new bug report. glusterfs-3.8.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://blog.gluster.org/2016/06/glusterfs-3-8-released/ [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user