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.
https://review.gluster.org/#/c/glusterfs/+/21366/
REVIEW: https://review.gluster.org/21366 (libglusterfs: change the validation type in dict_get_str_boolean) posted (#1) for review on master by Ravishankar N
The fix has caused others to pop up. For example: [2018-12-23 23:52:37.333162] I [dict.c:2619:dict_get_str_boolean] (-->/build/install/lib/glusterfs/6dev/xlator/mgmt/glusterd.so(+0xb3626) [0x7fc032ef3626] -->/build/install/lib/glusterfs/6dev/xlator/mgmt/glusterd.so(+0xaf8db) [0x7fc032eef8db] -->/build/install/lib/libglusterfs.so.0(dict_get_str_boolean+0x170) [0x7fc03e282008] ) 0-dict: key nfs.disable, integer type asked, has string type [Invalid argument] The reason being that nfs.disable (NFS_DISABLE_MAP_KEY) is set as string. For example: if (dict_get_str_boolean(volinfo->dict, NFS_DISABLE_MAP_KEY, 1)) { ret = dict_set_dynstr_with_alloc(volinfo->dict, NFS_DISABLE_MAP_KEY, "on"); The correct thing of course is to introduce a sane boolean setter/getter and be done with all those hacks ...
These warnings are not showing up no more in default logs.