+++ This bug was initially created as a clone of Bug #1236009 +++ 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: --- Additional comment from Anand Avati on 2015-07-02 05:16:18 EDT --- 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>
REVIEW: http://review.gluster.org/11545 (libgfapi: send explicit lookups on inodes linked in readdirp) posted (#1) for review on release-3.7 by Raghavendra Bhat (raghavendra)
COMMIT: http://review.gluster.org/11545 committed in release-3.7 by Niels de Vos (ndevos) ------ commit 69c434432853e2ba1ee53296f05c6a54ab300d02 Author: Raghavendra Bhat <raghavendra> Date: Fri Jun 12 15:12:05 2015 +0530 libgfapi: send explicit lookups on inodes linked in readdirp Backport of http://review.gluster.org/11236 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: I4230fae8e0b01a95c056282b08ed30832d4804a7 BUG: 1240190 Signed-off-by: Raghavendra Bhat <raghavendra> Reviewed-on: http://review.gluster.org/11545 Tested-by: NetBSD Build System <jenkins.org> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Shyamsundar Ranganathan <srangana> Reviewed-by: Niels de Vos <ndevos>
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.3, please open a new bug report. glusterfs-3.7.3 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://thread.gmane.org/gmane.comp.file-systems.gluster.devel/12078 [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user