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 <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gluster-users mailing list [email protected] http://supercolony.gluster.org/mailman/listinfo/gluster-users
