Bug 1531407
| Summary: | dict data type mismatches in the logs (for "link-count") | ||
|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Nithya Balachandran <nbalacha> |
| Component: | core | Assignee: | bugs <bugs> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | mainline | CC: | atumball, bugs, ravishankar |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-06-14 09:21:45 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This is not a bug in replicate. https://review.gluster.org/#/c/19062/ introduced some changes for gluster 4.0, wherein the dict_unserialize() function unconditionally assigned "data_t * value->data_type" to GF_DATA_TYPE_STR. Until the protocol changes for 4.0 support marshalling and unmarshalling of "data_t * value->data_type", the excessive logs should be fixed by https://review.gluster.org/#/c/19166/. The warnings are no more shown now, as we moved them to DEBUG mode. So, moving it as WORKSFORME. (as it resolves the flooding of mount logs). |
Description of problem: Mount logs flooded with (-->/usr/local/lib/glusterfs/4.0dev1/xlator/cluster/replicate.so(+0x78be7) [0x7fa3084d2be7] -->/usr/local/l ib/libglusterfs.so.0(dict_get_int8+0x5f) [0x7fa3164172ef] -->/usr/local/lib/libglusterfs.so.0(+0x18e84) [0x7fa316414e84] ) 0-dict: integer type asked, has string type [Invalid argument] When running tests/basic/afr/durability-off.t Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Checking in gdb, the main offender seems to the "link-count". (gdb) bt #0 dict_data_validate (data=0x7fa2fc014578, type=type@entry=GF_DATA_TYPE_INT) at dict.c:56 #1 0x00007fa3164172ef in dict_get_int8 (this=<optimized out>, key=<optimized out>, val=0x7fa30242763b "\001") at dict.c:1710 #2 0x00007fa3084d2be7 in afr_lookup_cbk (frame=0x7fa2f40019b8, cookie=0x1, this=0x7fa30400d7d0, op_ret=-1, op_errno=2, inode=0x7fa2f40021d8, buf=0x7fa302427780, xdata=0x7fa2fc000f98, postparent=0x7fa3024276e0) at afr-common.c:2812 #3 0x00007fa308742f6c in client3_3_lookup_cbk (req=0x7fa2f400ba18, iov=0x7fa2f400ba58, count=1, myframe=0x7fa2f400ee18) at client-rpc-fops.c:2866 #4 0x00007fa3161ed076 in rpc_clnt_handle_reply (clnt=0x7fa3040507d0, pollin=0x7fa2fc004760) at rpc-clnt.c:778 #5 0x00007fa3161ed626 in rpc_clnt_notify (trans=0x7fa304050af0, mydata=0x7fa304050800, event=RPC_TRANSPORT_MSG_RECEIVED, data=0x7fa2fc004760) at rpc-clnt.c:972 #6 0x00007fa3161e9642 in rpc_transport_notify (this=0x7fa304050af0, event=RPC_TRANSPORT_MSG_RECEIVED, data=0x7fa2fc004760) at rpc-transport.c:537 #7 0x00007fa30ac33bab in socket_event_poll_in (notify_handled=true, this=0x7fa304050af0) at socket.c:2447 #8 socket_event_handler (fd=<optimized out>, idx=<optimized out>, gen=<optimized out>, data=0x7fa304050af0, poll_in=<optimized out>, poll_out=<optimized out>, poll_err=0) at socket.c:2858 #9 0x00007fa31649643b in event_dispatch_epoll_handler (event_pool=0x2532040, event=0x7fa302427ea0) at event-epoll.c:579 #10 0x00007fa31649672e in event_dispatch_epoll_worker (data=0x7fa304050470) at event-epoll.c:655 #11 0x00007fa315279dc5 in start_thread () from /lib64/libpthread.so.0 #12 0x00007fa314bbe73d in clone () from /lib64/libc.so.6 (gdb) f 2 #2 0x00007fa3084d2be7 in afr_lookup_cbk (frame=0x7fa2f40019b8, cookie=0x1, this=0x7fa30400d7d0, op_ret=-1, op_errno=2, inode=0x7fa2f40021d8, buf=0x7fa302427780, xdata=0x7fa2fc000f98, postparent=0x7fa3024276e0) at afr-common.c:2812 2812 ret = dict_get_int8 (xdata, "link-count", &need_heal); (gdb) c You can ignore dict_data_validate (I wrote this as I cannot figure out how to break into a macro in GDB). xlators/cluster/afr/src/afr-common.c:1283: ret = dict_get_int8 (xdata, "link-count", &need_heal); xlators/cluster/afr/src/afr-common.c:1401: ret = dict_set_str (xdata, "link-count", GF_XATTROP_INDEX_COUNT); xlators/cluster/afr/src/afr-common.c:1404: "Unable to set link-count in dict "); xlators/cluster/afr/src/afr-common.c:1561: ret = dict_set_str (local->xattr_req, "link-count", xlators/cluster/afr/src/afr-common.c:1565: "Unable to set link-count in dict "); xlators/cluster/afr/src/afr-common.c:2573: ret = dict_set_str (dict, "link-count", GF_XATTROP_INDEX_COUNT); xlators/cluster/afr/src/afr-common.c:2576: "Unable to set link-count in dict "); xlators/cluster/afr/src/afr-common.c:2812: ret = dict_get_int8 (xdata, "link-count", &need_heal); xlators/cluster/afr/src/afr-common.c:2928: ret = dict_get_int8 (xdata, "link-count", &need_heal); xlators/cluster/afr/src/afr-self-heal-common.c:1681: ret = dict_get_int8 (xdata, "link-count", &need_heal); xlators/features/index/src/index.c:1462: /* TODO: Need to check what kind of link-counts are needed for xlators/features/index/src/index.c:2000: ret = dict_set_int8 (xdata, "link-count", 0); xlators/features/index/src/index.c:2004: "Unable to set link-count"); xlators/features/index/src/index.c:2006: ret = dict_set_int8 (xdata, "link-count", 1); xlators/features/index/src/index.c:2010: "Unable to set link-count"); xlators/features/index/src/index.c:2064: ret = dict_get_str (xattr_req, "link-count", &flag); xlators/features/index/src/index.c:2094: ret = dict_get_str (xdata, "link-count", &flag); Other offenders: GLUSTERFS_WRITE_IS_APPEND GLUSTERFS_OPEN_FD_COUNT