Bug 1636504 - Unwanted repeated logs in self heal daemon logs
Summary: Unwanted repeated logs in self heal daemon logs
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: GlusterFS
Classification: Community
Component: replicate
Version: 5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On: 1636502
Blocks: glusterfs-5.0
TreeView+ depends on / blocked
 
Reported: 2018-10-05 14:48 UTC by Shyamsundar
Modified: 2018-10-10 14:14 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1636502
Environment:
Last Closed: 2018-10-10 14:14:41 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Shyamsundar 2018-10-05 14:48:17 UTC
+++ This bug was initially created as a clone of Bug #1636502 +++

Description of problem:

Run a test that needs self heal (say bring down a brick, touch 10 files in others and bring the brick back up online). The self heal logs are filled with the following log message,

[dict.c:2775:dict_get_str_boolean] (-->/usr/local/lib/glusterfs/6dev/xlator/protocol/client.so(+0x6d6c0) [0x7f3bc5ad76c0] -->/usr/local/lib/glusterfs/6dev/xlator/cluster/replicate.so(+0x489ff) [0x7f3bc581d9ff] -->/usr/local/lib/libglusterfs.so.0(dict_get_str_boolean+0xcf) [0x7f3bd3f0c81f] ) 0-dict: key buf-has-zeroes, integer type asked, has unsigned integer type [Invalid argument]

NOTE: Line numbers may be off depending on which commit in master I tested with

This is being generated as, POSIX is encoding a uint32 in the dict for buf-has-zeroes" and AFR is reading a boolean, from code inspection as below,

afr-self-heal-data.c -> __checksum_cbk -> dict_get_str_boolean(xdata, "buf-has-zeroes" ...

posix-inode-fd-ops.c -> posix_rchecksum -> dict_set_uint32(rsp_xdata, "buf-has-zeroes"

The correction needs type safety, and hence the bug.

Comment 1 Shyamsundar 2018-10-10 14:14:41 UTC
This issue only existed in master, and the log cleanup patches takes care of the same. This was incorrectly cloned against release-5.


Note You need to log in before you can comment on or make changes to this bug.