[Bugs] [Bug 1755344] glustershd.log getting flooded with "W [inode.c:1017:inode_find] (-->/usr/lib64/glusterfs/6.0/xlator/cluster/disperse.so(+0xe3f9) [0x7fd09b0543f9] -->/usr/lib64/glusterfs/6.0/xlator/cluster/disperse.so(+0xe19c) [0x7fd09b05419 TABLE NOT FOUND"

bugzilla at redhat.com bugzilla at redhat.com
Wed Sep 25 09:50:00 UTC 2019


https://bugzilla.redhat.com/show_bug.cgi?id=1755344



--- Comment #1 from Xavi Hernandez <jahernan at redhat.com> ---
The problem appears when an inodelk contention notification is received by the
self-heal daemon. In this case, the function that manages it (ec_upcall() in
ec.c) does this:

        case GF_UPCALL_INODELK_CONTENTION:
            lc = upcall->data;
            if (strcmp(lc->domain, ec->xl->name) != 0) {
                /* The lock is not owned by EC, ignore it. */
                return _gf_true;
            }
            inode = inode_find(((xlator_t *)ec->xl->graph->top)->itable,
                               upcall->gfid);

In the case of self-heal daemon, ec->xl->graph->top corresponds to the
debug/io-stats xlator, which doesn't have any inode table. In this case this is
not a problem because self-heal doesn't use eager-locking, so no need to take
care of inodelk contention notifications. Locks will be released as soon as
possible regardless of whether there is contention or not.

Normal client mounts do have an inode table on the top xlator, so this problem
is not observed there.

I'll send a patch to prevent filling the logs in this case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Bugs mailing list