On 2020/2/2 下午8:45, Skibbi wrote:
> Hello,
> So I decided to try btrfs on my new portable WD Password Drive
> attached to Raspberry Pi 4. I created GPT partition, created luks2
> volume and formatted it with btrfs. Then I created 3 subvolumes and
> started copying data from other disks to one of the subvolumes. After
> writing around 40GB of data my filesystem crashed. That was super fast
> and totally discouraged me from next attempts to use btrfs :(
> But I would like to help with development so before I reformat my
> drive I can help you identifying potential issues with this filesystem
> by providing some debugging info.
> 
> Here are some details:
> 
> root@rpi4b:~# uname -a
> Linux rpi4b 4.19.93-v7l+ #1290 SMP Fri Jan 10 16:45:11 GMT 2020 armv7l GNU/Linux

Pretty old kernel, nor recently enough backports.

And since you're already using rpi4, no reason to use armv7 kernel.
You can go aarch64, Archlinux ARM has latest kernel for it.

> 
> root@rpi4b:~# btrfs --version
> btrfs-progs v4.20.1

Old progs too.

> 
> root@rpi4b:~# btrfs fi show
> Label: 'NAS'  uuid: b16b5b3f-ce5e-42e6-bccd-b48cc641bf96
>         Total devices 1 FS bytes used 42.48GiB
>         devid    1 size 4.55TiB used 45.02GiB path /dev/mapper/NAS
> 
> 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
> [201688.941552] BTRFS: device label NAS devid 1 transid 5 /dev/sda1
> [201729.894774] BTRFS info (device sda1): disk space caching is enabled
> [201729.894789] BTRFS info (device sda1): has skinny extents
> [201729.894801] BTRFS info (device sda1): flagging fs with big metadata feature
> [201729.902120] BTRFS info (device sda1): checking UUID tree
> [202297.695253] BTRFS info (device sda1): disk space caching is enabled
> [202297.695271] BTRFS info (device sda1): has skinny extents
> [202439.515956] BTRFS info (device sda1): disk space caching is enabled
> [202439.515976] BTRFS info (device sda1): has skinny extents
> [202928.275644] BTRFS error (device sda1): open_ctree failed
> [202934.389346] BTRFS info (device sda1): disk space caching is enabled
> [202934.389361] BTRFS info (device sda1): has skinny extents
> [203040.718845] BTRFS info (device sda1): disk space caching is enabled
> [203040.718863] BTRFS info (device sda1): has skinny extents
> [203285.351377] BTRFS error (device sda1): bad tree block start, want
> 31457280 have 0

This means some tree read failed miserably.
It looks like btrfs is trying to read something from trimmed range.

> [203285.383180] BTRFS error (device sda1): bad tree block start, want
> 31506432 have 0
> [203285.466743] BTRFS info (device sda1): read error corrected: ino 0
> off 32735232 (dev /dev/sda1 sector 80320)

This means btrfs still can get one good copy.

Something is not working properly, either from btrfs or the lower stack.

Have you tried to do the same thing without LUKS? Just btrfs over raw
partition.

And it's recommended to use newer kernel anyway.

Thanks,
Qu
> 
> --
> Best regards
>