Re: My first attempt to use btrfs failed miserably

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4338 bytes --]



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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]