On Sun, Feb 14, 2021 at 1:29 PM Neal Gompa <ngomp...@gmail.com> wrote:
> > Feb 14 15:20:49 localhost-live kernel: BTRFS info (device sda3): disk space > > caching is enabled > > Feb 14 15:20:49 localhost-live kernel: BTRFS info (device sda3): has skinny > > extents > > Feb 14 15:20:49 localhost-live kernel: BTRFS critical (device sda3): > > corrupt leaf: root=401 block=796082176 slot=15 ino=203657, invalid inode > > transid: has 888896 expect [0, 888895] > > Feb 14 15:20:49 localhost-live kernel: BTRFS error (device sda3): > > block=796082176 read time tree block corruption detected > > Feb 14 15:20:49 localhost-live kernel: BTRFS critical (device sda3): > > corrupt leaf: root=401 block=796082176 slot=15 ino=203657, invalid inode > > transid: has 888896 expect [0, 888895] > > Feb 14 15:20:49 localhost-live kernel: BTRFS error (device sda3): > > block=796082176 read time tree block corruption detected > > Feb 14 15:20:49 localhost-live kernel: BTRFS warning (device sda3): > > couldn't read tree root > > Feb 14 15:20:49 localhost-live kernel: BTRFS error (device sda3): > > open_ctree failed > > I've tried to do -o recovery,ro mount and get the same issue. I can't > seem to find any reasonably good information on how to do recovery in > this scenario, even to just recover enough to copy data off. > > I'm on Fedora 33, the system was on Linux kernel version 5.9.16 and > the Fedora 33 live ISO I'm using has Linux kernel version 5.10.14. I'm > using btrfs-progs v5.10. > > Can anyone help? >has 888896 expect [0, 888895] Off by one error. I haven't previously seen this with 'invalid inode transid'. There's an old kernel bug (long since fixed) that can inject garbage into the inode transid but that's not what's going on here. What do you get for: btrfs check --readonly In the meantime, it might be worth trying 5.11-rc7 or rc8 with the new 'ro,rescue=all' mount option and see if it can skip over this kind of problem. The "parent transid verify failed" are pretty serious, again not the same thing here. But I'm not sure how resilient repair is for either off by one errors, or bitflips still. -- Chris Murphy