On Sun, Feb 2, 2020 at 5:45 AM Skibbi <skibbi@xxxxxxxxx> wrote: > root@rpi4b:~# dmesg |grep btrfs > [223167.290255] BTRFS: error (device dm-0) in > btrfs_run_delayed_refs:2935: errno=-5 IO failure > [223167.389690] BTRFS: error (device dm-0) in > btrfs_run_delayed_refs:2935: errno=-5 IO failure > root@rpi4b:~# dmesg |grep BTRFS The entire unfiltered dmesg is needed. This older kernel doesn't have new enough Btrfs tree checker code to help determine what the problem is. > [203285.351377] BTRFS error (device sda1): bad tree block start, want > 31457280 have 0 > [203285.466743] BTRFS info (device sda1): read error corrected: ino 0 > off 32735232 (dev /dev/sda1 sector 80320) > [218811.383208] BTRFS error (device dm-0): bad tree block start, want > 50659328 have 7653333615399691647 These happening together suggest lower storage stack failure. Since kernel messages are filtered it only shows that Btrfs is working as designed, complaining about known bad file system metadata. But because it's filtered, it's not clear why the metadata has gone bad. > [223167.290255] BTRFS: error (device dm-0) in > btrfs_run_delayed_refs:2935: errno=-5 IO failure More suggestion of IO failure, whether physical device or logical layer in between Btrfs and physical device. Btrfs trusts the storage stack *less* than other file systems, by design. It's a kind of canary in the coal mine. Other file systems assume the storage stack is working, so they're less likely to complain. Only recent versions of e2fsprogs will format ext4 using metadata checksumming enabled. The kind of problems you're reporting look so bad and happen so fast I'd expect a good chance you'd reproduce the same problem with any metadata checksumming file system, if you have new enough progs to enable them. -- Chris Murphy
