On 02.02.2020 13:56 Qu Wenruo wrote: > > 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. I disagree. 4.19.y is an okay kernel to use w.r.t. btrfs, especially since all the newer stable versions currently have the statfs() is zero bug. The btrfs-tools version doesn't matter much, unless one has to use "btrfs check", which is (hopefully) not usually necessary. As you can see the kernel is also ~20 days old and 4.19.y is a LTS kernel, so it still gets (btrfs) updates/bugfixes. I would suspect a hardware issue with the WD disk (run badblocks for a while to check). The USB can also cause problems (the USB 3.0 DMA was a hack in RPI4 that wasn't merged upstream last I looked), but you didn't list the whole dmesg... > > Thanks, > Qu >> -- >> Best regards >>
