Description of problem:
using geo-replication with deep directory and lots of hardlinks can lead to "too many levels of symbolic links" error when files should be removed on the slave
Version-Release number of selected component (if applicable):
all of 4.1, but also in 3.12
needs special directory, in our case trees of node modules or ruby gems
Steps to Reproduce:
1. use rsnapshot to create backups of a virtual machine on the master
2. rsnapshot creates hardlinked copy of the synced tree to daily.0 which then get rotated
3. so .sync → daily.0, mv daily.0 daily.1 & .sync → daily.0
4. at end of rotation daily.6 is renamed to _delete.someid and gets removed.
the geo-replication of that deletion triggers the "too many levels of symbolic links" error, but after repeated attempts then finally manages to delete the hierarchy nevertheless, but geo-replication is forced back to history crawl and the process takes way too long.
no problems in removing files that it managed to create without problem earlier.
ruby gems and node collections are likely to trigger it, but need to be largish, but by no means excessive
# find /master_mnt/path/to/site/bundle/ruby/2.1.0/gems/ -type f |wc -l
# find /master_mnt/path/to/site/bundle/ruby/2.1.0/gems/ -type d |wc -l
the contents don't change frequently, so most of the files are hardlinks with 8 to 12 targets (.sync, daily.0 to daily.6, weekly.0 to weekly.3, _delete)
This bug is fixed in gluster 5 release.
Bugzilla link: https://bugzilla.redhat.com/show_bug.cgi?id=1597540, updating to next version will solve this problem.
Please confirm your gluster version and kindly close this bug.
I am closing this bug as the issue is addressed in release 5. Feel free to open new issue if you still face any problem.