Bug 1412135

Summary: rename of the same file from multiple clients with caching enabled may result in duplicate files
Product: [Community] GlusterFS Reporter: Susant Kumar Palai <spalai>
Component: distributeAssignee: Susant Kumar Palai <spalai>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: mainlineCC: amukherj, bugs, jthottan, kkeithle, nbalacha, nchilaka, rgowdapp, rhs-bugs, sbhaloth, skoduri, spalai, storage-qa-internal
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glusterfs-3.11.0 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1411352 Environment:
Last Closed: 2017-05-30 18:38:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1411352    

Comment 1 Worker Ant 2017-01-11 10:42:19 UTC
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)

Comment 2 Worker Ant 2017-01-11 12:21:35 UTC
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)

Comment 3 Worker Ant 2017-01-12 09:09:10 UTC
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)

Comment 4 Worker Ant 2017-01-19 12:33:30 UTC
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)

Comment 5 Worker Ant 2017-02-09 10:06:58 UTC
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)

Comment 6 Worker Ant 2017-02-15 07:13:28 UTC
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)

Comment 7 Worker Ant 2017-04-28 07:13:00 UTC
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)

Comment 8 Worker Ant 2017-04-29 14:28:42 UTC
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>

Comment 9 Shyamsundar 2017-05-30 18:38:45 UTC
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/