REVIEW: http://review.gluster.org/16375 (dht: send lookup on old name inside rename with bname and pargfid) posted (#1) for review on master by Susant Palai (spalai)
REVIEW: http://review.gluster.org/16375 (dht: send lookup on old name inside rename with bname and pargfid) posted (#2) for review on master by Susant Palai (spalai)
REVIEW: http://review.gluster.org/16375 (dht: send lookup on old name inside rename with bname and pargfid) posted (#3) for review on master by Susant Palai (spalai)
REVIEW: http://review.gluster.org/16375 (dht: send lookup on old name inside rename with bname and pargfid) posted (#4) for review on master by Susant Palai (spalai)
REVIEW: https://review.gluster.org/16375 (dht: send lookup on old name inside rename with bname and pargfid) posted (#5) for review on master by Susant Palai (spalai)
REVIEW: https://review.gluster.org/16375 (dht: send lookup on old name inside rename with bname and pargfid) posted (#6) for review on master by Susant Palai (spalai)
REVIEW: https://review.gluster.org/16375 (dht: send lookup on old name inside rename with bname and pargfid) posted (#7) for review on master by Susant Palai (spalai)
COMMIT: https://review.gluster.org/16375 committed in master by Raghavendra G (rgowdapp) ------ commit 8b2ef5076284e44a87698393c8094c925fa863fa Author: Susant Palai <spalai> Date: Wed Jan 11 16:04:47 2017 +0530 dht: send lookup on old name inside rename with bname and pargfid Inside rename, a lookup is done on the source name to make sure that the file is there. But we used to do a gfid based lookup and hence, even if the source name was renamed to a new name from some other client, lookup will be successful as server3_3_lookup will fetch the new path based on the gfid. So even if the source file does not exist any more rename will carry on, and as server3_3_link(destination is hashed to a different brick other than source cached scenario) also does gfid based resolve, it wont detect that the source name does not exist and hardlink creation will be successful (since gfid based resolve will get the new dentry). To solve this problem, do a name based lookup inside rename. So that rename will fail right away if the source does not exist. Change-Id: Ieba8bdd6675088dbf18de90ed4622df043d163bd BUG: 1412135 Signed-off-by: Susant Palai <spalai> Reviewed-on: https://review.gluster.org/16375 Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> Reviewed-by: N Balachandran <nbalacha> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Raghavendra G <rgowdapp>
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.11.0, please open a new bug report. glusterfs-3.11.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://lists.gluster.org/pipermail/announce/2017-May/000073.html [2] https://www.gluster.org/pipermail/gluster-users/