On Sun, Dec 29, 2019 at 6:40 AM Matthias Neuer <mneuer@xxxxxx> wrote: > > Hi, > > since I updated my system I noticed a lot of messages like the following > in dmesg (sda8 is /home). > > BTRFS critical (device sda8): corrupt leaf: root=1 block=78397440 > slot=32, invalid root item size, have 239 expect 439 > > I did a 'btrfs scrub' but it didn't find any errors. Then I started the > system in single user mode and tried 'btrfs check' but again, no error > could be found. Scrub compares block contents with its checksum, if there's a match, no error is reported. But the contents of the leaf might not be valid, with the leaf's checksum based on that corruption. In recent kernels there's a tree checker that does a validation check. The tree checker code is what you've hit, and it's saying there's a problem with the leaf contents. Depending on the update you did, it's possible that this is corrupt leaf has been there for a while, and is only just now showing up with the newish tree checker code, in 5.2 and 5.3 kernels. > I read that the issue could come from bad RAM and so I ran memtest86+ > for 12h but it seems my RAM is ok. Could be the result of a Btrfs bug in an older kernel, and it's only now being caught because of the tree checker. > > Is this a real problem and how can I fix it? > Good question. The kernel message is very convincing, in that it suggests it knows exactly what the problem is and what the expected value should be. I'd like to believe 'btrfs check' could fix it. What do you get for: btrfs insp dump-t -b 78397440 /dev/ If there are filenames in the output you can remove/sanitize them. btrfs check /dev/ This should give a good idea whether --repair can fix it, but we'll need to hear from a developer about it first. In the meantime you can make sure the backup is current. -- Chris Murphy
