On 2020/2/2 下午9:29, Martin Raiber wrote: > 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... You see, the support for RPI4 is not in LTS kernel branch either... Thus I recommend to go latest or even latest rc just like archlinuxarm is providing. Thanks, Qu > >> >> Thanks, >> Qu >>> -- >>> Best regards >>> >
Attachment:
signature.asc
Description: OpenPGP digital signature
