Re: My first attempt to use btrfs failed miserably

[Chris Murphy <lists@colorremedies.com>]

On Sun, Feb 2, 2020 at 5:45 AM Skibbi <skibbi@gmail.com> 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