>>
>> Here I can't spot a filename.
>
> This is a node. It points to leafs. So what we're looking for depends
> on the exact kernel error that you got the block number from.

Ah, ok. So when I do a

# btrfs insp dump-t -b 285405184 --follow /dev/sda8

I get quite a lengthy output with leafes (and filenames) in it (see attachment).
The last line is

ERROR: child eb corrupted: parent bytenr=285405184 item=13 parent level=1 child level=1

I give you an idea how the errors appear in journalctl:

[...]
Dec 30 08:46:27 matze-debian kernel: BTRFS critical (device sda8): corrupt leaf: root=1 block=60403712 slot=32, invalid root item size, have 239 expect 439
Dec 30 08:46:28 matze-debian kernel: BTRFS critical (device sda7): corrupt leaf: root=1 block=63807488 slot=26, invalid root item size, have 239 expect 439
Dec 30 08:46:43 matze-debian kernel: BTRFS critical (device sda5): corrupt leaf: root=1 block=64675840 slot=21, invalid root item size, have 239 expect 439
Dec 30 08:47:03 matze-debian kernel: BTRFS critical (device sda8): corrupt leaf: root=1 block=60923904 slot=32, invalid root item size, have 239 expect 439
Dec 30 08:47:05 matze-debian kernel: BTRFS critical (device sda7): corrupt leaf: root=1 block=56455168 slot=26, invalid root item size, have 239 expect 439
Dec 30 08:47:19 matze-debian kernel: BTRFS critical (device sda5): corrupt leaf: root=1 block=64929792 slot=21, invalid root item size, have 239 expect 439
Dec 30 08:47:45 matze-debian kernel: BTRFS critical (device sda8): corrupt leaf: root=1 block=61784064 slot=32, invalid root item size, have 239 expect 439
Dec 30 08:48:11 matze-debian kernel: BTRFS critical (device sda5): corrupt leaf: root=1 block=64499712 slot=21, invalid root item size, have 239 expect 439
Dec 30 08:48:21 matze-debian kernel: BTRFS critical (device sda8): corrupt leaf: root=1 block=62066688 slot=32, invalid root item size, have 239 expect 439
Dec 30 08:48:52 matze-debian kernel: BTRFS critical (device sda5): corrupt leaf: root=1 block=64860160 slot=21, invalid root item size, have 239 expect 439
Dec 30 08:49:23 matze-debian kernel: BTRFS critical (device sda8): corrupt leaf: root=1 block=62222336 slot=32, invalid root item size, have 239 expect 439
Dec 30 08:49:28 matze-debian kernel: BTRFS critical (device sda5): corrupt leaf: root=1 block=65261568 slot=21, invalid root item size, have 239 expect 439
Dec 30 08:50:31 matze-debian kernel: BTRFS critical (device sda5): corrupt leaf: root=1 block=65839104 slot=21, invalid root item size, have 239 expect 439
Dec 30 08:51:16 matze-debian kernel: BTRFS critical (device sda8): corrupt leaf: root=1 block=63418368 slot=32, invalid root item size, have 239 expect 439
Dec 30 08:51:32 matze-debian kernel: BTRFS critical (device sda5): corrupt leaf: root=1 block=65859584 slot=21, invalid root item size, have 239 expect 439
Dec 30 08:51:57 matze-debian kernel: BTRFS critical (device sda8): corrupt leaf: root=1 block=63668224 slot=32, invalid root item size, have 239 expect 439
Dec 30 08:52:18 matze-debian kernel: BTRFS critical (device sda5): corrupt leaf: root=1 block=66072576 slot=21, invalid root item size, have 239 expect 439
Dec 30 08:52:48 matze-debian kernel: BTRFS critical (device sda8): corrupt leaf: root=1 block=64548864 slot=32, invalid root item size, have 239 expect 439
Dec 30 08:52:50 matze-debian kernel: BTRFS critical (device sda5): corrupt leaf: root=1 block=66195456 slot=21, invalid root item size, have 239 expect 439
Dec 30 08:53:24 matze-debian kernel: BTRFS critical (device sda8): corrupt leaf: root=1 block=64688128 slot=32, invalid root item size, have 239 expect 439
Dec 30 08:53:26 matze-debian kernel: BTRFS critical (device sda5): corrupt leaf: root=1 block=66277376 slot=21, invalid root item size, have 239 expect 439
[...]

The difference in root item size seems to be the same all the time ("have 239 expect 439").

> So btrfs check has no errors but you're still seeing corruption
> messages from the kernel? What about using check with the
> --mode=lowmem option? It's a lot slower.

Exactly. This is the output when running the check with lowmem:

[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs done with fs roots in lowmem mode, skipping
[7/7] checking quota groups skipped (not enabled on this FS)
Opening filesystem to check...
Checking filesystem on /dev/sda8
UUID: d6954ba3-3d50-4886-ae3f-a92a5ca83923
found 17174376448 bytes used, no error found
total csum bytes: 16457960
total tree bytes: 241557504
total fs tree bytes: 190373888
total extent tree bytes: 23085056
btree space waste bytes: 67493294
file data blocks allocated: 23684820992
  referenced 16014913536

>> I backup up all my data.
>> I wonder if these errors would be gone if I reinstalled my system and copied back my data.
>> Would cost me a few hours but maybe not more than trying to fix this.
>
> If it's not causing grief yet, I'd give it a few days for a developer
> to reply about what might be going on. And whether it can be fixed.
>
> But yes, this is metadata corruption. So a new file system won't have
> the problem.

I thought so, but was not completely sure. So I don't have a problem waiting a few days.

Regards,
Matthias