<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>thnx ;-)!</div><div><br></div><div>I filed</div><div><br></div><a class="bz_bug_link 
          bz_status_NEW " title="NEW - log files get flooded when removexattr() can't find a specified key or value" href="https://bugzilla.redhat.com/show_bug.cgi?id=1144527" style="color: rgb(102, 153, 204); text-decoration: none; font-family: 'DejaVu Sans', 'Liberation Sans', sans-serif; font-weight: bold; ">Bug 1144527</a><br><div apple-content-edited="true">
<div style="background-color:#FFFFFF; color:#000000;">
  
</div>

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