Hide Forgot
Description of problem: ========================== I was verifying 1408836 - [ganesha+ec]: Contents of original file are not seen when hardlink is created I am seeing this Problem with mdcache+distributed-ecvolume+nfsganesha I removed nfsganesha out of the equation and didn't seem to hit it(though i would like to give another try) When I mount a dist-ec volume on two nfs ganesha clients(different vips) from c1==>I created a file f1, which hashes to 1st dht subvol c1,c2===>i did a stat of f1 c2==>renamed file f1 to f2 which hashes to the same dht-subvol c1--->try to do this immediately, preferably within few seconds, without doing any lookups or anything do a rename of f1 to f3(which must hash to a different dht-subvol we expect that to error out , but instead the rename passes and you can see both on clients and bricks two file f2, f3 in this case the files are duplicates. If these files are of huge size, then we may end up consuming double the space unncessarily I am able to reproduce with about 80% consistency Version-Release number of selected component (if applicable): ================================== Volume Name: ecvol Type: Distributed-Disperse Volume ID: 55f976ee-0c5e-49dc-9616-1e9abed0c7ec Status: Started Snapshot Count: 0 Number of Bricks: 3 x (4 + 2) = 18 Transport-type: tcp Bricks: Brick1: 10.70.35.37:/rhs/brick2/ecvol Brick2: 10.70.35.116:/rhs/brick2/ecvol Brick3: 10.70.35.239:/rhs/brick2/ecvol Brick4: 10.70.35.135:/rhs/brick2/ecvol Brick5: 10.70.35.8:/rhs/brick2/ecvol Brick6: 10.70.35.196:/rhs/brick2/ecvol Brick7: 10.70.35.37:/rhs/brick3/ecvol Brick8: 10.70.35.116:/rhs/brick3/ecvol Brick9: 10.70.35.239:/rhs/brick3/ecvol Brick10: 10.70.35.135:/rhs/brick3/ecvol Brick11: 10.70.35.8:/rhs/brick3/ecvol Brick12: 10.70.35.196:/rhs/brick3/ecvol Brick13: 10.70.35.37:/rhs/brick4/ecvol Brick14: 10.70.35.116:/rhs/brick4/ecvol Brick15: 10.70.35.239:/rhs/brick4/ecvol Brick16: 10.70.35.135:/rhs/brick4/ecvol Brick17: 10.70.35.8:/rhs/brick4/ecvol Brick18: 10.70.35.196:/rhs/brick4/ecvol Options Reconfigured: performance.md-cache-timeout: 600 performance.cache-invalidation: on performance.stat-prefetch: on features.cache-invalidation-timeout: 600 ganesha.enable: on features.cache-invalidation: on transport.address-family: inet performance.readdir-ahead: on nfs.disable: on nfs-ganesha: enable cluster.enable-shared-storage: enable [root@dhcp35-37 ~]# rpm -qa|grep gluster glusterfs-events-3.8.4-11.el7rhgs.x86_64 glusterfs-rdma-3.8.4-11.el7rhgs.x86_64 glusterfs-api-3.8.4-11.el7rhgs.x86_64 glusterfs-server-3.8.4-11.el7rhgs.x86_64 nfs-ganesha-gluster-2.4.1-3.el7rhgs.x86_64 glusterfs-libs-3.8.4-11.el7rhgs.x86_64 glusterfs-cli-3.8.4-11.el7rhgs.x86_64 glusterfs-3.8.4-11.el7rhgs.x86_64 glusterfs-fuse-3.8.4-11.el7rhgs.x86_64 glusterfs-debuginfo-3.8.4-11.el7rhgs.x86_64 glusterfs-client-xlators-3.8.4-11.el7rhgs.x86_64 python-gluster-3.8.4-11.el7rhgs.noarch glusterfs-ganesha-3.8.4-11.el7rhgs.x86_64 glusterfs-geo-replication-3.8.4-11.el7rhgs.x86_64 [root@dhcp35-37 ~]# rpm -qa|grep ganesha nfs-ganesha-gluster-2.4.1-3.el7rhgs.x86_64 nfs-ganesha-debuginfo-2.4.1-3.el7rhgs.x86_64 nfs-ganesha-2.4.1-3.el7rhgs.x86_64 glusterfs-ganesha-3.8.4-11.el7rhgs.x86_64 [root@dhcp35-37 ~]# How reproducible: =================== most of the times
client side: client1: [root@rhs-client45 dir2]# stat x1 File: ‘x1’ Size: 0 Blocks: 0 IO Block: 1048576 regular empty file Device: 2ah/42d Inode: 12109031449775892209 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:nfs_t:s0 Access: 2017-01-09 20:00:16.000000000 +0530 Modify: 2017-01-09 20:00:16.000000000 +0530 Change: 2017-01-09 20:00:16.000000000 +0530 Birth: - [root@rhs-client45 dir2]# mv x1 x4 [root@rhs-client45 dir2]# ls x2 x4 [root@rhs-client45 dir2]# [root@rhs-client45 dir2]# [root@rhs-client45 dir2]# ll total 0 -rw-r--r--. 2 root root 0 Jan 9 2017 x2 -rw-r--r--. 2 root root 0 Jan 9 2017 x4 [root@rhs-client45 dir2]# client2: root@dhcp35-107 ganesha]# cd dir2 [root@dhcp35-107 dir2]# stat x1 File: `x1' Size: 0 Blocks: 0 IO Block: 1048576 regular empty file Device: 1fh/31d Inode: 12109031449775892209 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2017-01-09 20:00:16.493823000 +0530 Modify: 2017-01-09 20:00:16.493823000 +0530 Change: 2017-01-09 20:00:18.036401827 +0530 [root@dhcp35-107 dir2]# mv x1 x2 [root@dhcp35-107 dir2]# ll total 0 -rw-r--r--. 2 root root 0 Jan 9 20:00 x2 -rw-r--r--. 2 root root 0 Jan 9 20:00 x4 [root@dhcp35-107 dir2]# one of the ec node bricks: [root@dhcp35-37 ~]# ll /rhs/brick*/ecvol/ganesha/dir2 /rhs/brick2/ecvol/ganesha/dir2: total 0 /rhs/brick3/ecvol/ganesha/dir2: total 0 ---------T. 2 root root 0 Jan 9 20:00 x4 /rhs/brick4/ecvol/ganesha/dir2: total 0 -rw-r--r--. 3 root root 0 Jan 9 20:00 x2 -rw-r--r--. 3 root root 0 Jan 9 20:00 x4 [root@dhcp35-37 ~]# In this case it was a zerobyte file, but i saw the problem even with non-zerobyte file which was consuming duplicate space
I am able to reproduce even on distrep volume with ganesha mount and mdcache settings Note: both the clients use different ganesha vips to mount simple steps: 1)create from c1: files x1..x10, note down which file hashes to which dhtsubvol 2)now delete all files 3)now create again a file x1 from c1 4)now stat and ls of x1 on both c1 and c2 5)from c2: rename x1 to another filename which hashes to same subvol 6)from c1: immediately, within few seconds,without doing any kind of lookups, rename x1 to a file which hashes to different subvol. both 5,6 passes hence we have duplicate files as below: dht-subvol1: [root@dhcp35-37 ~]# ll /rhs/brick*/distrep/ganesha/dir1/ total 0 -rw-r--r--. 3 root root 0 Jan 10 12:47 x10 -rw-r--r--. 3 root root 0 Jan 10 12:47 x3 dht-subvol2: [root@dhcp35-239 ~]# ll /rhs/brick*/distrep/ganesha/dir1/ total 0 ---------T. 2 root root 0 Jan 10 12:47 x3
Renaming the title to reflect the problem only with ganesha and not with mdcache I have retried this same scenario without mdcache settings. I am able to reproduce the issue with Ganesha+distributed-(ec/replicate) volume Also, changing component to ganesha
proposing as blocker, as this can lead to duplicate files and unncessary disk space. Also, why is ganesha not re-validating the cache when a write operation is happening(in this case rename)???
Looks like issue with dht/bricks.. Even if ganesha server1 would have done rename from f1 to f3, brick processes should have returned ENOENT for f1 instead of creating f3 or alteast rename f2 to f3 if only gfid is considered instead of filename. Could you please try the test with pure replicate / disperse volume? Also CCin dht team to have a look.
Also could u please try the test using gNFS/fuse mount with md-cache timout set to 600 sec as well? thanks!
(In reply to Soumya Koduri from comment #7) > Also could u please try the test using gNFS/fuse mount with md-cache timout > set to 600 sec as well? thanks! This problem has nothing to do with mdcache Also, I see this only on any form of distributed volume(pure distribute/dist-rep/dist-ec) with nfs-ganesha mount type I have tried with fuse but not able to hit the issue
I even tried with fuse+mdcache, but i couldn't recreate the problem on that setup
I could reproduce this issue using two fuse mounts as well. Unlike nfs-ganesha server, fuse mounts doesnt have caching enabled by default. So to reproduce this issue on fuse, I have made use of md-cache. Have following settings enabled on the volume - [root@dhcp35-197 ~]# gluster v info brick_vol Volume Name: brick_vol Type: Distribute Volume ID: d8f43c74-54c2-4349-a195-5eff2685b707 Status: Started Snapshot Count: 0 Number of Bricks: 2 Transport-type: tcp Bricks: Brick1: 192.168.122.201:/bricks/brick_vol Brick2: 192.168.122.201:/bricks/brick_vol1 Options Reconfigured: performance.md-cache-timeout: 600 performance.cache-invalidation: on performance.stat-prefetch: on features.cache-invalidation-timeout: 600 features.cache-invalidation: off transport.address-family: inet performance.readdir-ahead: on nfs.disable: off [root@dhcp35-197 ~]# [root@dhcp35-197 ~]# Note here I turned off 'features.cache-invalidation' so that the requests are cached in md-cache and not invalidated by upcall. Have 2 fuse mounts of the same volume - [root@dhcp35-197 ~]# mount | grep gluster localhost:/brick_vol on /fuse-mnt type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,allow_other,max_read=131072) localhost:/brick_vol on /fuse-mnt1 type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,allow_other,max_read=131072) [root@dhcp35-197 ~]# mount1: [root@dhcp35-197 fuse-mnt]# touch abc bricks: [root@dhcp35-197 ~]# ls -ltr /bricks/brick_vol* /bricks/brick_vol: total 0 /bricks/brick_vol1: total 4 -rw-r--r--. 2 root root 0 Jan 10 17:04 abc [root@dhcp35-197 ~]# mount2: [root@dhcp35-197 fuse-mnt1]# stat abc File: ‘abc’ Size: 0 Blocks: 0 IO Block: 131072 regular empty file Device: 2bh/43d Inode: 13211023334685081894 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:fusefs_t:s0 Access: 2017-01-10 17:04:54.334845000 +0530 Modify: 2017-01-10 17:04:54.334845000 +0530 Change: 2017-01-10 17:04:54.334845640 +0530 Birth: - [root@dhcp35-197 fuse-mnt1]# [root@dhcp35-197 fuse-mnt1]# mv abc abcd [root@dhcp35-197 fuse-mnt1]# bricks: [root@dhcp35-197 ~]# ls -ltr /bricks/brick_vol* /bricks/brick_vol: total 0 /bricks/brick_vol1: total 4 -rw-r--r--. 2 root root 0 Jan 10 17:04 abcd [root@dhcp35-197 ~]# mount1: [root@dhcp35-197 fuse-mnt]# mv abc abdcde [root@dhcp35-197 fuse-mnt]# bricks: [root@dhcp35-197 ~]# ls -ltr /bricks/brick_vol* /bricks/brick_vol1: total 8 -rw-r--r--. 3 root root 0 Jan 10 17:04 abdcde -rw-r--r--. 3 root root 0 Jan 10 17:04 abcd /bricks/brick_vol: total 4 ---------T. 2 root root 0 Jan 10 17:05 abdcde [root@dhcp35-197 ~]# [root@dhcp35-197 ~]# getfattr -m . -de hex /bricks/brick_vol*/* getfattr: Removing leading '/' from absolute path names # file: bricks/brick_vol1/abcd security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a64656661756c745f743a733000 trusted.gfid=0x558981d7d14243c0b756fbba574d0126 # file: bricks/brick_vol1/abdcde security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a64656661756c745f743a733000 trusted.gfid=0x558981d7d14243c0b756fbba574d0126 # file: bricks/brick_vol/abdcde security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a64656661756c745f743a733000 trusted.gfid=0x558981d7d14243c0b756fbba574d0126 trusted.glusterfs.dht.linkto=0x627269636b5f766f6c2d636c69656e742d3100 [root@dhcp35-197 ~]# [root@dhcp35-197 ~]# ls -ltr /bricks/brick_vol* /bricks/brick_vol1: total 8 -rw-r--r--. 3 root root 0 Jan 10 17:04 abdcde -rw-r--r--. 3 root root 0 Jan 10 17:04 abcd /bricks/brick_vol: total 4 ---------T. 2 root root 0 Jan 10 17:05 abdcde [root@dhcp35-197 ~]# This may not be supported configuration. But these steps may help debugging and to further narrow down the issue. As suspected the issue doesn't seem to be specific to ganesha - could be in dht or posix layer. Susant is currently taking a look at it. Please correct the components when needed.
Yesterday when I tried saw the issue getting reproduced on nag's setup, I did not see dht_rename log for the 2nd rename. "Why so" is yet to be rcaed. Will keep posting after trying the above reproducer. -Susant
Thanks Susant. To add, this issue seem to happen on fuse_mnt even with server-side cache_invalidation on (supported configuration). Just that we need to issue commands very quick (as done in comment#13) to trigger this issue.
Yes Soumya, able to reproduce with cache_invalidation on. Thanks for the reproducer.
RCA(dht-part) Tried to reproduce the issue with the reproducer given by Soumya on a two fuse mounts. command: touch /fuse-mnt/abc; ls /fuse-mnt2/abc; stat /fuse-mnt2/abc ; mv /fuse-mnt2/abc /fuse-mnt2/abcd ; mv /fuse-mnt/abc /fuse-mnt/abcde logs from: fuse-mnt2 (1st rename) [2017-01-11 07:39:24.565003] I [MSGID: 109066] [dht-rename.c:1576:dht_rename] 0-test1-dht: renaming /abc (hash=test1-client-1/cache=test1-client-1) => /abcd (hash=test1-client-1/cache=<nul>) [2017-01-11 07:39:24.565022] I [dht-rename.c:1471:dht_rename_lock] 0-DHT: Going rename for path:/abc [2017-01-11 07:39:24.565205] I [dht-rename.c:1378:dht_rename_lock_cbk] 0-test1-dht: Lock taken [2017-01-11 07:39:24.565375] I [dht-rename.c:1345:dht_rename_lookup_cbk] 0-test1-dht: lookup done on path:(null) So hashed and cached are same for both old and new, hence rename was issued and all done. logs from: fuse-mnt (2nd rename) [2017-01-11 07:39:24.578832] I [MSGID: 109066] [dht-rename.c:1576:dht_rename] 0-test1-dht: renaming /abc (hash=test1-client-1/cache=test1-client-1) => /abcde (hash=test1-client-0/cache=<nul>) [2017-01-11 07:39:24.578857] I [dht-rename.c:1471:dht_rename_lock] 0-DHT: Going rename for path:/abc [2017-01-11 07:39:24.579364] I [dht-rename.c:1378:dht_rename_lock_cbk] 0-test1-dht: Lock taken [2017-01-11 07:39:24.579943] I [dht-rename.c:1345:dht_rename_lookup_cbk] 0-test1-dht: lookup done on path:(null) [2017-01-11 07:39:24.579967] I [MSGID: 0] [dht-rename.c:1274:dht_rename_create_links] 0-test1-dht: will create link files on test1-client-1 for path:/abc [2017-01-11 07:39:24.579988] I [dht-linkfile.c:126:dht_linkfile_create] 0-test1-dht: linkfile_Creation invoked path:/abc subvol:test1-client-0 [2017-01-11 07:39:24.582420] I [dht-rename.c:1142:dht_rename_linkto_cbk] 0-test1-dht: hard link create, subvol:test1-client-1 old:/abc new:/abcde [2017-01-11 07:39:24.584885] W [MSGID: 109034] [dht-rename.c:647:dht_rename_unlink_cbk] 0-test1-dht: /abc: Rename: unlink on test1-client-1 failed [No such file or directory] [2017-01-11 07:39:29.057840] I [xlator.c:831:loc_touchup] 0-server: Doing gfid based resolve for path:/ In this case the destination file hashes to a new brick. So the step is to create a linkto file with the source name on destination hashed brick, create hardlink of the destination name on the source cached brick and unlink the source name on the source hashed brick. The problem: After taking the inodelk on source cached brick on the source file, rename op sends a lookup on the source name to make sure the file exist. But it does a gfid based lookup, which will be successful as even though the 1st rename has renamed the file from /abc to /abcd, the gfid for the both is same and this lookup will be successful. The solution would be to do a name based lookup. Will run this solution to check whether it solves the issue. -Susant
Forgot to add a little more detail. (In reply to Susant Kumar Palai from comment #18) > RCA(dht-part) > > Tried to reproduce the issue with the reproducer given by Soumya on a two > fuse mounts. > > command: touch /fuse-mnt/abc; ls /fuse-mnt2/abc; stat /fuse-mnt2/abc ; mv > /fuse-mnt2/abc /fuse-mnt2/abcd ; mv /fuse-mnt/abc /fuse-mnt/abcde > > > logs from: fuse-mnt2 (1st rename) > [2017-01-11 07:39:24.565003] I [MSGID: 109066] > [dht-rename.c:1576:dht_rename] 0-test1-dht: renaming /abc > (hash=test1-client-1/cache=test1-client-1) => /abcd > (hash=test1-client-1/cache=<nul>) > [2017-01-11 07:39:24.565022] I [dht-rename.c:1471:dht_rename_lock] 0-DHT: > Going rename for path:/abc > [2017-01-11 07:39:24.565205] I [dht-rename.c:1378:dht_rename_lock_cbk] > 0-test1-dht: Lock taken > [2017-01-11 07:39:24.565375] I [dht-rename.c:1345:dht_rename_lookup_cbk] > 0-test1-dht: lookup done on path:(null) > > So hashed and cached are same for both old and new, hence rename was issued > and all done. > > > logs from: fuse-mnt (2nd rename) > [2017-01-11 07:39:24.578832] I [MSGID: 109066] > [dht-rename.c:1576:dht_rename] 0-test1-dht: renaming /abc > (hash=test1-client-1/cache=test1-client-1) => /abcde > (hash=test1-client-0/cache=<nul>) > [2017-01-11 07:39:24.578857] I [dht-rename.c:1471:dht_rename_lock] 0-DHT: > Going rename for path:/abc > [2017-01-11 07:39:24.579364] I [dht-rename.c:1378:dht_rename_lock_cbk] > 0-test1-dht: Lock taken > [2017-01-11 07:39:24.579943] I [dht-rename.c:1345:dht_rename_lookup_cbk] > 0-test1-dht: lookup done on path:(null) > [2017-01-11 07:39:24.579967] I [MSGID: 0] > [dht-rename.c:1274:dht_rename_create_links] 0-test1-dht: will create link > files on test1-client-1 for path:/abc > [2017-01-11 07:39:24.579988] I [dht-linkfile.c:126:dht_linkfile_create] > 0-test1-dht: linkfile_Creation invoked path:/abc subvol:test1-client-0 > [2017-01-11 07:39:24.582420] I [dht-rename.c:1142:dht_rename_linkto_cbk] > 0-test1-dht: hard link create, subvol:test1-client-1 old:/abc new:/abcde > [2017-01-11 07:39:24.584885] W [MSGID: 109034] > [dht-rename.c:647:dht_rename_unlink_cbk] 0-test1-dht: /abc: Rename: unlink > on test1-client-1 failed [No such file or directory] > [2017-01-11 07:39:29.057840] I [xlator.c:831:loc_touchup] 0-server: Doing > gfid based resolve for path:/ > > In this case the destination file hashes to a new brick. So the step is to > create a linkto file with the source name on destination hashed brick, > create hardlink of the destination name on the source cached brick and > unlink the source name on the source hashed brick. > > The problem: After taking the inodelk on source cached brick on the source > file, rename op sends a lookup on the source name to make sure the file > exist. But it does a gfid based lookup, which will be successful as even > though the 1st rename has renamed the file from /abc to /abcd, the gfid for > the both is same and this lookup will be successful. Post this lookup, dht creates hardlink of destination file. Since server-xlator does gfid based resolution, even though dht passed "abc" which should not be existing, it will be successful and will fetch the new path which is /abcd. At the end dht does unlink of the old name, which failed anyway you can see in log above. > > The solution would be to do a name based lookup. Will run this solution to > check whether it solves the issue. > > > -Susant
After applying the patch, I am not seeing the issue anymore. <patch> diff --git a/xlators/cluster/dht/src/dht-helper.c b/xlators/cluster/dht/src/dht-helper.c index ad031b6..f2b946b 100644 --- a/xlators/cluster/dht/src/dht-helper.c +++ b/xlators/cluster/dht/src/dht-helper.c @@ -530,7 +530,10 @@ dht_lock_new (xlator_t *this, xlator_t *xl, loc_t *loc, short type, */ lock->loc.inode = inode_ref (loc->inode); loc_gfid (loc, lock->loc.gfid); - + lock->loc.path = gf_strdup (loc->path); + lock->loc.parent = inode_ref (loc->parent); + lock->loc.name = strrchr (loc->path, '/'); + gf_uuid_copy (lock->loc.pargfid, loc->pargfid);; out: return lock; } diff --git a/xlators/cluster/dht/src/dht-rename.c b/xlators/cluster/dht/src/dht-rename.c index 4dfcec7..d5104bc 100644 --- a/xlators/cluster/dht/src/dht-rename.c +++ b/xlators/cluster/dht/src/dht-rename.c @@ -1341,8 +1341,9 @@ dht_rename_lookup_cbk (call_frame_t *frame, void *cookie, xlator_t *this, local->is_linkfile = _gf_true; } - gf_log (this->name, GF_LOG_INFO, "lookup done on path:%s", - local->lock.locks[0]->loc.path); + gf_log (this->name, GF_LOG_INFO, "lookup done on path:%s op_ret:%d " + "is_linkfile:%d", local->lock.locks[0]->loc.path, op_ret, + local->is_linkfile); </patch> logs: t-1) => /abcde (hash=test1-client-0/cache=<nul>) [2017-01-11 09:58:28.062472] I [dht-rename.c:1472:dht_rename_lock] 0-DHT: Going rename for path:/abc [2017-01-11 09:58:28.062851] I [dht-rename.c:1379:dht_rename_lock_cbk] 0-test1-dht: Lock taken [2017-01-11 09:58:28.063334] I [dht-rename.c:1346:dht_rename_lookup_cbk] 0-test1-dht: lookup done on path:/abc op_ret:-1 is_linkfile:1 Lookup failed which used to be successful all this time. From the mount point. ------------------------- [root@vm1 ~]# touch /fuse-mnt/abc; ls /fuse-mnt2/abc; stat /fuse-mnt2/abc ; mv /fuse-mnt2/abc /fuse-mnt2/abcd ; mv /fuse-mnt/abc /fuse-mnt/abcde /fuse-mnt2/abc File: '/fuse-mnt2/abc' Size: 0 Blocks: 0 IO Block: 131072 regular empty file Device: 2ch/44d Inode: 9319321045353352602 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:fusefs_t:s0 Access: 2017-01-11 15:28:28.029401000 +0530 Modify: 2017-01-11 15:28:28.029401000 +0530 Change: 2017-01-11 15:28:28.030401207 +0530 Birth: - mv: cannot move '/fuse-mnt/abc' to '/fuse-mnt/abcde': No such file or directory Will send a patch soon.
Thanks Susant. Correcting the component as the fix shall be available as part of the glusterfs builds.
upstream patch: http://review.gluster.org/#/c/16375/
Would like nfs-ganesha team to test the patch once on a nfs-ganesha setup as mentioned by QA.
Reproduced this issue on 3.2 by following the steps mentioned in Comment 13 and followed the same steps for verifying this BZ against 3.8.4-27.el7rhgs.x86_64. After the fix, we are not seeing any duplicate files when renamed the same file from multiple mounts with cache enabled. Moving this BZ to Verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2774
Reproduced this issue on 3.10.7 Is there any plan to fix it?
(In reply to tusj from comment #35) > Reproduced this issue on 3.10.7 > Is there any plan to fix it? This is a downstream RHGS BZ. From your comment, it looks like you have reproduced this on an upstream version. Please update the upstream community BZ instead.