Bug 1090220

Summary: GETXATTR of non-existent xattr should not result in error being logged
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Ben England <bengland>
Component: glusterdAssignee: Pranith Kumar K <pkarampu>
Status: CLOSED EOL QA Contact: storage-qa-internal <storage-qa-internal>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.1CC: amukherj, nlevinki, nsathyan, vbellur
Target Milestone: ---Keywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-03 17:13:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1212172    

Description Ben England 2014-04-23 01:16:53 UTC
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.

Comment 5 Ben England 2015-05-15 11:45:22 UTC
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.

Comment 6 Vivek Agarwal 2015-12-03 17:13:22 UTC
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.