*** Bug 1328000 has been marked as a duplicate of this bug. ***
The fix we thought is to move the log in posix_mknod to DEBUG level
A 2x2 dis-rep volume , mounted on cifs client and running different fops on client using crefi, following error messages are seen in brick logs: [2016-09-19 07:06:54.089211] E [MSGID: 113001] [posix-helpers.c:1175:posix_handle_pair] 0-testvol-posix: /mnt/brick/testvol/b2/thread0/level00/hardlink_to_files/57df8e7 3%%YLW8207V72: key:trusted.glusterfs.dht.linktoflags: 1 length:20 [File exists] [2016-09-19 07:06:54.089256] E [MSGID: 113001] [posix.c:1353:posix_mknod] 0-testvol-posix: setting xattrs on /mnt/brick/testvol/b2/thread0/level00/hardlink_to_files/57d f8e73%%YLW8207V72 failed [2016-09-19 07:06:54.145984] E [MSGID: 113001] [posix-helpers.c:1175:posix_handle_pair] 0-testvol-posix: /mnt/brick/testvol/b2/thread0/level00/hardlink_to_files/57df8e7 4%%2BTFGH1HJS: key:trusted.glusterfs.dht.linktoflags: 1 length:20 [File exists] [2016-09-19 07:06:54.146008] E [MSGID: 113001] [posix.c:1353:posix_mknod] 0-testvol-posix: setting xattrs on /mnt/brick/testvol/b2/thread0/level00/hardlink_to_files/57d f8e74%%2BTFGH1HJS failed
Below are the steps to reproduce the issue on plain distributed environment touch file{1..20} for i in `seq 1 20`; do ln file$i filehl$i; done for i in `seq 1 20`; do mv file$i new_file$i; done RCA: file rename operation is successful but message is coming in brick logs "key:trusted.glusterfs.dht.linkto error:File exists". The messages are coming in logs because call (sys_lsetxattr) is returning error code(EEXIST) and it is returning error because key xattr is already exists on the file before run rename operation.To avoid the message need to put a check(EEXIST) before print the message.
(In reply to Mohit Agrawal from comment #7) > Below are the steps to reproduce the issue on plain distributed environment > > touch file{1..20} > for i in `seq 1 20`; do ln file$i filehl$i; done > for i in `seq 1 20`; do mv file$i new_file$i; done > > RCA: file rename operation is successful but message is coming in brick logs > "key:trusted.glusterfs.dht.linkto error:File exists". > The messages are coming in logs because call (sys_lsetxattr) is > returning > error code(EEXIST) and it is returning error because key xattr is > already > exists on the file before run rename operation.To avoid the message > need to > put a check(EEXIST) before print the message. Can we be sure that the value of the xattr is the same?
lsetxattr returns EEXIST only when same attribute already exists on the file so i believe the value is same. Regards Mohit Agrawal
Please ignore my last comment not sure about the value,value could be different only attribute name is same but in both cases (value is same or different) it will update new value to the xattr. Regards Mohit Agrawal
Verified this BZ on glusterfs version: 3.12.2-4.el7rhgs.x86_64. Followed the same steps as in the description and Comment 7. Rename is successful and logs didn't throw any errors mentioned in the BZ. Hence, moving this BZ to Verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:2607