+++ This bug was initially created as a clone of Bug #1350179 +++ Description of problem: Distributed geo-replication generates errors in its geo-replication geo.log file on tge master when replicating symlinked directories or files. An example of such an error taken from this log file: [2016-06-25 23:57:58.566375] E [master(/data/myvolume/brick):784:log_failures] _GMaster: ENTRY FAILED: ({'gfid': 'f2156f11-505a-4bb7-a697-8da4a97e622d', 'entry': '.gfid/aa5198e7-fc88-4135-863b-a69e451df450/vphn.c', 'stat': {'atime': 1466618772.882145, 'gid': 0, 'mtime': 1462143151.0, 'mode': 41471, 'uid': 0}, 'link': '../../../../../arch/powerpc/mm/vphn.c', 'op': 'SYMLINK'}, 2) This error is also reported in the "gluster volume geo-replication status detail" command under the FAILURES column. The number reported under the FAILURES count matches the number of error lines found in the log file mentioned above. Nevertheless the symlinked files and directories exists on the slave so they have been replicated but still an error is reported. Version-Release number of selected component (if applicable): GlusterFS 3.7.11 on Debian 8 How reproducible: I just took a linux kernel tarball which contains a few symbolic links of files and directories and unpacked it onto my volume and then started geo-replication for the first time. Steps to Reproduce: 1. setup two nodes replica volume 2. unpack linux-4.6-rc6.tar.xz (taken from kernel.org) onto that volume (contains 23 symbolic links) 3. setup distributed geo-replication to slave node and start geo-replication Actual results: 23 FAILURES reported under the status details of geo replication command and 23 errors in the geo.log file on the master Expected results: 0 FAILURES and 0 error lines in the geo.log log file Additional info: Using Debian 8.5 on all nodes --- Additional comment from Kaushal on 2017-03-08 05:54:10 EST --- This bug is getting closed because GlusteFS-3.7 has reached its end-of-life. Note: This bug is being closed using a script. No verification has been performed to check if it still exists on newer releases of GlusterFS. If this bug still exists in newer GlusterFS releases, please reopen this bug against the newer release.
I found this bug after running into the exact same problem. Am running Debian 8 (3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux) glusterfs-client 3.10.1-1 glusterfs-common 3.10.1-1 glusterfs-server 3.10.1-1 When first starting geo replication between the hosts. I have some errors exactly as described in the original bug. [2017-05-05 15:22:28.919220] E [master(/bricks/coderepo_data_ssd/coderepo1):762:log_failures] _GMaster: ENTRY FAILED: ({'gfid': '1c3dca94-8de2-4085-a37d-b2b01f7b2752', 'entry': '.gfid/52850b33-ab27-4a04-a172-402e343d4d52/file_name.xml', 'stat': {'atime': 1493932757.5763855, 'gid': 0, 'mtime': 1357762164.0, 'mode': 41471, 'uid': 0}, 'link': 'dir_name/file_name.xml', 'op': 'SYMLINK'}, 2) Was asked on IRC to clone this bug and assign to 3.10 Let me know if I need to provide anymore info.
Hi Carl, Thanks for cloning the bug. I will take this bug and will get back to you if any thing needed. Rafi
Is anymore information needed? I am happy to provide anything else. Is there any documentation on gluster replication and symlinks? If i re-setup the volume and remove the symlinks before geo-replication starts there are 0 errors. Unfortunately I do need symlinks to be there on other volumes. Thanks, Carl
Hi, I initially opened the original bug #1350179 one year ago which got closed without evening being resolved. Now we are one year later and I have upgraded to GlusterFS version 3.8.11 and I still have the exact same problem. This bug makes geo-replication really a pain with GlusterFS as it happens quite often and I don't really understand why this is not being fixed. Thank you in advance for giving this issue higher priority. Best regards, John
Is there anything we can adjust in geo-rep to have it see the symlink exists on the replica while this is being looked into? Thanks, Carl
This bug reported is against a version of Gluster that is no longer maintained (or has been EOL'd). See https://www.gluster.org/release-schedule/ for the versions currently maintained. As a result this bug is being closed. If the bug persists on a maintained version of gluster or against the mainline gluster repository, request that it be reopened and the Version field be marked appropriately.