[Gluster-users] logfiles get flooded by warnings

[bernhard glomm]

thnx ;-)!

I filed

Bug 1144527

forgot to say that the bricks where running on zol, 
which looked perfectly so far.

Bernhard


On Sep 19, 2014, at 4:44 PM, Niels de Vos <ndevos at redhat.com> wrote:

> On Fri, Sep 19, 2014 at 07:35:39PM +0530, Vijay Bellur wrote:
>> On 09/19/2014 01:56 PM, Bernhard Glomm wrote:
>>> Hi all,
>>> 
>>> I'm running
>>> #: glusterfs -V
>>> #: glusterfs 3.4.5 built on Aug  6 2014 19:15:07
>>> on ubuntu 14.04 from the semiosis ppa
>>> 
>>> I have a replica 2 with 2 servers
>>> another client does a fuse mount of a volume.
>>> On rsyncing a bit of data onto the fuse mount,
>>> I get an entry like the below one on the client - for each file that
>>> is copied onto the volume
>>> 
>>> [2014-09-19 07:57:39.877806] W
>>> [client-rpc-fops.c:1232:client3_3_removexattr_cbk]
>>> 0-<volume_name>-client-0: remote operation failed: No data available
>>> [2014-09-19 07:57:39.877963] W
>>> [client-rpc-fops.c:1232:client3_3_removexattr_cbk]
>>> 0-<volume_name>-client-1: remote operation failed: No data available
>>> [2014-09-19 07:57:39.878462] W [fuse-bridge.c:1172:fuse_err_cbk]
>>> 0-glusterfs-fuse: 21741144: REMOVEXATTR()
>>> /<path_to_file>/.<file_name_with_a_leading_dot> => -1 (No data available)
>>> 
>>> The data itself is present and accessible on the volume and on both bricks.
>>> 
>>> So three questions:
>>> a.) what kind of data is not available? what is the client complaining
>>> about?
>> 
>> This problem is being seen for a removexattr() operation. The client would
>> have sent a request for an extended attribute to be removed from a file or
>> directory. No data available/ENODATA error is seen when the file or
>> directory does not have the key of the extended attribute which was
>> requested to be removed. Performing strace of rsync might give a clue about
>> the key of the extended attribute.
>> 
>>> b.) since it is a warning and the data seems to be okay - is there
>>> anything I need to fix?
>> 
>> Usually this warning is benign in nature.
>> 
>>> c.) How can I get rid of the amount of log lines? it's more than 3GB/day..
>>> 
>> 
>> You can possibly have a logrotate policy to rotate based on the size of the
>> log file.
>> 
>> I have sent across a patch to avoid flooding logs with removexattr warning
>> messages when the error happens to be ENODATA or ENOATTR [1].
>> 
>> Regards,
>> Vijay
>> 
>> [1] http://review.gluster.org/#/c/8781/
> 
> The patch looks ok, there just needs a bug to be filed and included in
> the comments.
> 
> In the bug report (and maybe in the commit message), the log message
> should get listed. This will help other users to find the bug and fix.
> 
> Could someone file a bug for this and post the bug number as a reply?
> - https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS&component=protocol
> 
> Thanks,
> Niels

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140919/23d33a58/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140919/23d33a58/attachment.sig>