On Wed, Dec 04, 2019 at 01:32:59PM +0200, Nikolay Borisov wrote: > > > On 4.12.19 г. 13:04 ч., Christian Höppner wrote: > > Hello, > > > > I'm writing because the kernel wiki page relating to this error[1] says to > > write here first. > > > > I'm (was) running Arch Linux, kernel 5.4.1, btrfs-progs 5.3.1 > > > > Yesterday during usage, the root file system remounted read-only. I was > > dumb enough to react by rebooting the machine, when I was greeted by the > > following error: > > > > [ 25.634530] BTRFS critical (device nvme0n1p2): corrupf leaf: block=810145234944... > > How come you omitted exactly the most useful error that could have > pointed at the problem ? If the data is intact on-disk and the leaf > checker triggered this means you likely have faulty ram. Yesterday on IRC there was a similar case where the metadata in the extent tree had nonsense generation values, but the rest of the filesystem was fine. It was very specific: only the generation fields in several extent items (sometimes even consecutive ones!). Bad RAM is usually much more chaotic: different fields are corrupted, and some or all of them will cause a more visible failure than mere mismatched transid. https://pastebin.com/raw/GemSDdin Also it turned out that the filesystem was made in 2014. Maybe there was an old kernel bug that was putting garbage in extent generation numbers, and this is the last remnant of it. If such a bug was known in 2014, it might explain why btrfs doesn't seem to detect it today. btrfs check, read, and delete all said nothing about the mismatched gen field. I'd expect at least check and delete to notice the gen field mismatch--after all, they are inspecting or manipulating the extent item and the extent data reference already, so there's no significant performance loss compared to not doing the check at the same time. > > [ 25.634793] BTRFS error (device nvme0n1p2): block=810145234944 read time tree block corruption detected > > [ 25.634961] BTRFS error (device nvme0n1p2): in __btrfs_free_extent:3080: errno=-5 IO failure > > [ 25.635042] BTRFS error (device nvme0n1p2): in btrfs_run_delayed_refs:2188: errno=-5 IO failure > > [ 34.653440] systemd-journald[483]: Failed to torate /var/log/journal/8f7037b10bbd4f25aadd3d19105ef920/system.journal > > > > After booting to live media, I checked SMART, badblocks, `btrfs check > > --readonly` and `btrfs scrub`. All came back clean. I conclude that this > > is a false positive, and have downgraded the kernel to 5.3.13 as a > > workaround. > > > > How can I provide more information to help? > > > > [1]: https://btrfs.wiki.kernel.org/index.php/Tree-checker#How_to_handle_such_error > >
Attachment:
signature.asc
Description: PGP signature
