WARNING: CPU: 0 PID: 5655 at fs/btrfs/backref.c:1255 find_parent_nodes+0xac7/0xf90 [btrfs] about bees HOT 11 CLOSED

This is around here, it's always the crawler thread that exposes this kernel backtrace:

1244         /*
1245          * This walks the tree of merged and resolved refs. Tree blocks are
1246          * read in as needed. Unique entries are added to the ulist, and
1247          * the list of found roots is updated.
1248          *
1249          * We release the entire tree in one go before returning.
1250          */
1251         node = rb_first(&preftrees.direct.root);
1252         while (node) {
1253                 ref = rb_entry(node, struct prelim_ref, rbnode);
1254                 node = rb_next(&ref->rbnode);
1255                 WARN_ON(ref->count < 0);
1256                 if (roots && ref->count && ref->root_id && ref->parent == 0) {
1257                         if (sc && sc->root_objectid &&
1258                             ref->root_id != sc->root_objectid) {
1259                                 ret = BACKREF_FOUND_SHARED;
1260                                 goto out;
1261                         }

from bees.

I've been seeing that warning for years. It's a lot more common post-v4.14 (it occurs about once an hour on v4.12, once a minute on v4.14).

I'm not sure whether the various if (...ref->count...) statements do useful things when ref->count is negative. Whatever they do seems to be mostly harmless, given the thousands of times it has occurred for me over the past few years. I wonder if this could lead to things like FIEMAP falsely reporting extents as shared (possibly causing nodatacow to fail unnecessarily)?

from bees.

I think I saw something about ref->count in 4.14.13, I'll look if I can identify the patch again... Hang on...

from bees.

Can't find it... No idea where I found it. I'll try to ignore it keeping in mind that you're seeing it much more often without any visible effects.

from bees.

Maybe torvalds/linux@ec35e48 which was also cherry-picked for v4.14.13.

I haven't tested that yet, but I don't think it affects this WARN_ON. A comment elsewhere states that ref->count may be negative for delayed refs, and bees probably ends up calling LOGICAL_INO on a lot of those.

from bees.

Yes, I found this, too. Maybe I'm confusing with an older commit that actually replaced an WARN_ON(...)

from bees.

This happens on v4.14.14 too.

There was an earlier commit that touched this WARN_ON, but it didn't make a semantic change, it was just a code cleanup.

from bees.

https://www.spinics.net/lists/linux-btrfs/msg74077.html

Assuming that the above patch is accepted, the offending kernel warning will be killed.

from bees.

Nice work...

Would it make sense to guard the WARN_ON with if (node->action != BTRFS_DROP_DELAYED_REF) then, so it is still caught in other cases, instead of removing it completely?

from bees.

That would be a good question for the list. Sprinkling the code with random WARN_ONs is generally frowned upon without a compelling reason--probably to avoid having issues like this pop up 7 years later.

from bees.

This has been merged into upstream kernels 4.14.29 and 4.16-rc2. 4.9.x, 4.4x, and other LTS kernels don't need it because it doesn't affect them.

from bees.