Description of problem: This bug is with reference to https://bugzilla.redhat.com/show_bug.cgi?id=1345732. When we try renaming a directory it ends up creating a nested directory of the same gfid. With an existing distribute replicate volume with samba ctdb setup and VSS plugin. On a cifs mount when any directory say "xyz" is renamed to ".xyz" it is observed that it ends up creating "xyz/.xyz" Version-Release number of selected component (if applicable): glusterfs-3.7.9-9.el7rhgs.x86_64 samba-client-4.4.3-7.el7rhgs.x86_64 How reproducible: 1/1 Steps to Reproduce: 1.In an existing setup with Distributed-Replicate volume with samba-ctdb setup and VSS plugins 2.Do a cifs mount and mount the share in windows8 as well 3.Create files,directories in the share. 3.Play a video file (not necessarily from the same directory which will be renamed in the below steps) 4.goto cifs mount rename any directory containing files say "xyz" to ".xyz" 5.Goto windows share right click on "xyz" properties and check the Hidden checkbox. 6.Goto the cifs mount location and rename again ".xyz" to "xyz" 7.Double click on "xyz" Actual results: Share was not accessible.The video which was being played crashed in mid way. Expected results: Should not be any issue Additional info:
Findings on inode link failure: The rename command "mv samba2 .samba2" ends up creating samba2/.samba2 directory structure, both samba2 and .samba2 having same gfid. This could be because of a known race in rename in dht, Raghavendra G will update on this. Below is the backend details when we end up in this scenario. All the bricks have a .samba2 directory created inside samba2: # ll -R /bricks/brick2/DOG_brick?/samba2 -a drwxr-xr-x. 2 root root 6 Jun 13 04:35 .samba2 GFIDs of both the directories are same: # getfattr -e hex -dm - /bricks/brick2/DOG_brick0/samba2 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/DOG_brick0/samba2 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.afr.DOG-client-1=0x000000000000000000000000 trusted.gfid=0x408e7032cc0f479fa450b17302802adf trusted.glusterfs.dht=0x00000001000000007fffffffffffffff user.DOSATTRIB=0x30783132000003000300000011000000120000000000000000000000000000000000000000000000804917afa9c0d1010000000000000000 # getfattr -e hex -dm - /bricks/brick2/DOG_brick0/samba2/.samba2 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/DOG_brick0/samba2/.samba2 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.gfid=0x408e7032cc0f479fa450b17302802adf trusted.glusterfs.dht=0x00000001000000007fffffffffffffff user.DOSATTRIB=0x30783130000003000300000011000000100000000000000000000000000000000000000000000000804917afa9c0d1010000000000000000 # ll /bricks/brick2/DOG_brick3/.glusterfs/40/8e/ total 0 lrwxrwxrwx. 1 root root 55 Jun 7 10:45 408e7032-cc0f-479f-a450-b17302802adf -> ../../00/00/00000000-0000-0000-0000-000000000001/samba2 A lookup is issued by fuse on /samba2/.samba2, dht_lookup_dir_cbk() --> dht_selfheal_directory() --> inode_link() is called, inode detects that there is a cyclic loop in the dentry and hence returns error.
We have known issues related to rename and lookup heal race like bz 1118770. Consider following scenario during mv samba2 .samba2 (which is the first rename above): 1. rename was successful on some subvols of DHT but not on all. 2. A lookup on samba2 was issued and this results in healing of samba2 on those subvols where rename is yet to be issued. 3. rename completes and say a lookup on samba2 was issued again. At the end of this we've samba2 and .samba2 on all subvols (both having same gfid). Now a second mv .samba2 samba2 can create a directory samba2/.samba2
Tried to reproduce this bug on gluster v3.8.4-12 Samba version 4.5.5 There were no crashing of video as stated above after renaming operation. This bug should be closed.
Version samba-4.7.5-103.el7rhgs.x86_64 glusterfs-server-3.12.2-8.el7rhgs.x86_64 Followed the steps to reproduce and the issue is not seen in the above version.
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/RHSA-2018:2607