[Bugs] [Bug 1239109] geo-rep session goes faulty when symlinks copied in archive mode

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1239109

Rahul Hinduja <rhinduja at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rhinduja at redhat.com



--- Comment #6 from Rahul Hinduja <rhinduja at redhat.com> ---
In another scenario where the symlink is copied via absolute path and not with
relative path following errors are reported in the logs: 


[root at 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 at 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 at dhcp47-155 .processed]# cd ../.processing
[root at dhcp47-155 .processing]# ls
CHANGELOG.1488275454  CHANGELOG.1488276806
[root at 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 at 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..

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Fda6r30vNq&a=cc_unsubscribe