Dealing with BTRFS ref/backpointer mismatches, backref missing

Question

A btrfs filesystem reported some errors during btrfs receive operation due to some missing extends. From the log:

BTRFS error (device dm-1): unable to find ref byte nr 190303420416 \
      parent 0 root 594  owner 1 offset 0
BTRFS: error (device dm-1) in __btrfs_free_extent:6944: errno=-2 No such entry
BTRFS info (device dm-1): forced readonly
BTRFS: error (device dm-1) in btrfs_run_delayed_refs:2956: errno=-2 No such entry

A btrfs scrub (after a umount + mount) failed with similar errors.

A btrfs check reports issues for 3 extends - each extend issue is reported like this:

checking extents
ref mismatch on [190303420416 16384] extent item 0, found 1
Backref 190303420416 parent 594 root 594 not found in extent tree
backpointer mismatch on [190303420416 16384]
owner ref check failed [190303420416 16384]

My question is: how can I translate those numbers to something useful? For example to check if some files/directories are impacted?

And how to deal with such errors?

A btrfs check --repair seems to work without complaining severely:

  ref mismatch on [190303420416 16384] extent item 0, found 1
* repair deleting extent record: key 190303420416 169 1
* adding new tree backref on start 190303420416 len 16384 parent 0 root 594
  Backref 190303420416 parent 594 root 594 not found in extent tree
  backpointer mismatch on [190303420416 16384]
  owner ref check failed [190303420416 16384]

(the * marks are mine)

Does this mean that the repair was successful without loosing any data?

Answer 1

A successful btrfs check --repair command doesn't necessarily yield a consistent btrfs filesystem.

In one case I observed that a btrfs scrub after btrfs check triggered several WARN_ON() tests in fs/btrfs/extent-tree.c. And receiving snapshot yielded an IO failure (which forced a readonly remount).

Thus, since the runtimes of a btrfs check, followed by a btrfs check --repair and a btrfs scrub can be quite significant - and those actions have uncertain outcomes: a practical alternative is to just re-create the btrfs filesystem and restore a backup.