Description of problem: Log messages such as ones shown in "actual results" should not happen. It is perfectly normal behavior for an application to request an XATTR that does not exist on a file, just as it is perfectly normal behavior for an application to try to open a file that does not exist. Gluster should not log errors or informational messages in situations like this. It slows down Gluster and can fill the system disk. If user really wants to trace Gluster activity they can use systemtap for example. For many message logging calls, the overhead of computing the procedure call arguments is incurred even if a message is not logged. Version-Release number of selected component (if applicable): RHS 2.1 U2 - glusterfs-3.4.0.49 How reproducible: Not easy to do, not sure how I got to this situation, but the log is unambiguous. Actual results: saw hundreds of repetitions of this message sequence for different GFIDs. [2014-04-22 21:49:50.544642] I [server-rpc-fops.c:868:server_fgetxattr_cbk] 0-ira-server: 3588434: FGETXATTR 56 (4f7cb046-2c31-4214-9998-47fc8da2d0e7) (system.posix_acl_access) ==> (No data available) [2014-04-22 21:49:50.568816] E [posix.c:3539:posix_fgetxattr] 0-ira-posix: fgetxattr failed on key system.posix_acl_access (No data available) Expected results: these messages should not be logged. Additional info: was using 2 servers with 2-replica Gluster volume and SMB share exported by them. Windows 7 client was running smallfile benchmark to create and delete files. At one point the brick glusterfsd process was not running, when I brought it back, I saw a lot of these errors being logged.
I now realize that this should not have been a low-priority bz, because Gluster fills system disks with such log messages. Gluster should not normally log any condition that could be reasonably expected to happen in normal operation, unless the user raises the log level to DEBUG. In the above situation, if the SMB layer is sure that the system.posix_acl_access xattr should have already been written, then this layer should log the error, but not the posix translator (posix.c) layer, since it has no knowledge of whether the xattr should already have been written or not.
Thank you for submitting this issue for consideration in Red Hat Gluster Storage. The release for which you requested us to review, is now End of Life. Please See https://access.redhat.com/support/policy/updates/rhs/ If you can reproduce this bug against a currently maintained version of Red Hat Gluster Storage, please feel free to file a new report against the current release.