Hide Forgot
i have a two node setup which is configured for replication mode (raid 1). i observed the following behaviour. 0. the config files have been created using glusterfs-volgen as described in the installation manual. 1. setup a shared volume in raid 1 mode 2. start glusterfsd on both nodes 3. mount the volume on both nodes on /export (for example) 4. execute the following commands: cd /export touch file 5. stop the glusterfsd on one node (e.g. node two) 6. execute the following commands cd /export ln -s /export/file test (absolute path is mandatory to provoke the failure) 7. start the glusterfsd again 8. wait until the clients connect to the newly started daemon 9. execute the following command (on any of the nodes) ls /export this command will lead to a hang stating the following debug infos on the newly started node: [2010-05-03 12:18:09] D [server-resolve.c:238:resolve_path_deep] brick1: RESOLVE READLINK() seeking deep resolution of /test [2010-05-03 12:18:09] D [server-protocol.c:2188:server_readlink_cbk] server-tcp: 13: READLINK /test (0) ==> -1 (No such file or directory) a umount -f /export on the newly started glusterfs node followed by a mount /export resolves the problem. however this is not as expected.
I am pretty sure I am also running into this. I did not do the same debugging session but realized this happened because some extended attribute were set on one node and not the other. Eg, you can reproduce it by creating the symlink while both daemons are running, then manually adding: setfattr -h -n trusted.afr.node1 -v 0sAAAAAQAAAAEAAAAA symlink I hope this gets solved soon, while this is not the case it is unsafe to use absolute symlinks.
PATCH: http://patches.gluster.com/patch/5069 in master (storage/posix: prevent chmod() from getting called on symlinks)
Most of the self-heal (replicate related) bugs are now fixed with 3.1.0 branch. As we are just week behind the GA release time.. we would like you to test the particular bug in 3.1.0RC releases, and let us know if its fixed.
I guess we should not be having anymore issues with symlink self-healing. Avati, can you confirm and update the bug status?
PATCH: http://patches.gluster.com/patch/5808 in release-3.0 (storage/posix: prevent chmod() from getting called on symlinks)
PATCH: http://patches.gluster.com/patch/5817 in release-3.0 (check if the file is a symlink while doing utimes)
verified,works with 3.0.7qa2.
PATCH: http://patches.gluster.com/patch/5818 in master (check whether the file is a symlink while doing utimes)
Internal enhancement, User need not be bothered.