Description of problem: copying directory (like /etc) in archive mode (cp -a) causes geo-rep session to go faulty. Version-Release number of selected component (if applicable): How reproducible: Create geo-rep session between master , slave. carry out copy using cp -af to master. geo-rep session should go faulty Steps to Reproduce: 1. Create geo-rep session 2. cp -af /etc /mnt/master where /mnt/master is mounted master volume 3. check geo-rep session status. Actual results: Session goes faulty. Expected results: Session should be active. Errors if any, should be logged from Slave to master. Additional info: Copy should involve files like /etc/mtab which is actually a symbolic link to a proc file.(/etc/mtab -> /proc/self/mounts)
REVIEW: http://review.gluster.org/11530 (geo-rep: ignore EPERM during meta operation) posted (#1) for review on master by Saravanakumar Arumugam (sarumuga)
REVIEW: http://review.gluster.org/11530 (geo-rep: ignore EPERM during meta operation) posted (#2) for review on master by Saravanakumar Arumugam (sarumuga)
REVIEW: http://review.gluster.org/11530 (geo-rep: ignore EPERM during meta operation) posted (#3) for review on master by Saravanakumar Arumugam (sarumuga)
REVIEW: http://review.gluster.org/11530 (geo-rep: ignore EPERM during meta operation) posted (#4) for review on master by Saravanakumar Arumugam (sarumuga)
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
In another scenario where the symlink is copied via absolute path and not with relative path following errors are reported in the logs: [root@dhcp47-167 vol1]# grep -ri "1b7c66c1-7d1c-4885-a61a-d880ecb9aa3f" * ssh%3A%2F%2Froot%4010.70.43.249%3Agluster%3A%2F%2F127.0.0.1%3Avols.log:[2017-02-28 10:13:25.850085] E [master(/bricks/brick1/br1):785:log_failures] _GMaster: META FAILED: ({'go': '.gfid/1b7c66c1-7d1c-4885-a61a-d880ecb9aa3f', 'stat': {'atime': 1488276791.0739934, 'gid': 0, 'mtime': 1488276791.0739934, 'mode': 41471, 'uid': 0}, 'op': 'META'}, 2) [root@dhcp47-167 vol1]# The above I saw on nfs-ganesha mount where for somereason the setattr is getting recorded in the changelog upon creating of symlink as: [root@dhcp47-155 .processed]# cd ../.processing [root@dhcp47-155 .processing]# ls CHANGELOG.1488275454 CHANGELOG.1488276806 [root@dhcp47-155 .processing]# grep -ri "1b7c66c1-7d1c-4885-a61a-d880ecb9aa3f" * CHANGELOG.1488276806:E 1b7c66c1-7d1c-4885-a61a-d880ecb9aa3f SYMLINK 77703c46-8257-4924-b84c-b97f5dbceaf5%2Fsym_file_rahul CHANGELOG.1488276806:M 1b7c66c1-7d1c-4885-a61a-d880ecb9aa3f SETATTR [root@dhcp47-155 .processing]# If master and slave volume are mounted on same client, it still can acess the link path. But usually they are different and it will not have access to the file even when both the actual and symlink file are synced to the slave and available, it wont have access to the data..
*** This bug has been marked as a duplicate of bug 1455559 ***