Re: filesystem corrupt - error -117

[Robert Krig <robert.krig@render-wahnsinn.de>]

[-- Attachment #1.1.1: Type: text/plain, Size: 6567 bytes --]

If you are on Debian 10, you can enable backports and install both a 
kernel and btrfs-progs from backports. This would of course require a 
reboot. Apart from that, this shouldn't conflict with any other 
dependencies, unless you have something that explicitly relies on the 
installed kernel version.



On 26.10.21 09:24, Qu Wenruo wrote:
>
>
> On 2021/10/26 14:03, Mia wrote:
>> Hi Qu,
>>
>> thanks for clarification.
>> So I should just ignore these errors for now?
>
> Yes, none of them is going to cause any direct problems.
>
>> What about these ones, you haven't mentioned:
>> bad metadata [342605463552, 342605479936) crossing stripe boundary
>
> This is the same, it just means it crosses 64K boundary, which is not
> supported for the incoming subpage support (using 4K page size on 64K
> page size systems).
>
>>
>> Problem with updating is that this is currently still Debian 10 and a
>> production environment and I don't know when it is possible to upgrade
>> because of dependencies.
>
> OK, understood the situation now.
>
> Then I can't provide much helper as I'm not familiar with Debian...
>
> If not reproducible so far, I can only recommend for a memtest to rule
> out memory bitflip, which could also cause the bug.
>
> Thanks,
> Qu
>>
>> Regards
>> Mia
>>
>> ------ Originalnachricht ------
>> Von: "Qu Wenruo" <quwenruo.btrfs@gmx.com>
>> An: "Mia" <9speysdx24@kr33.de>; "Qu Wenruo" <wqu@suse.com>;
>> linux-btrfs@vger.kernel.org
>> Gesendet: 26.10.2021 00:45:18
>> Betreff: Re: filesystem corrupt - error -117
>>
>>>
>>>
>>> On 2021/10/26 01:09, Mia wrote:
>>>> Hi Qu,
>>>>
>>>> sorry for the late reply. I tried the btrfs check again with arch
>>>> live cd:
>>>>
>>>> root@archiso ~ # uname -a
>>>> Linux archiso 5.11.16-arch1-1 #1 SMP PREEMPT Wed, 21 Apr 2021 17:22:13
>>>> +0000 x86_64 GNU/Linux
>>>> root@archiso ~ # btrfs --version
>>>> btrfs-progs v5.14.2
>>>>
>>>> https://gist.github.com/lynara/12dcfff870260b6bc35b9d1137921fc4
>>>
>>> OK, so the metadata problem is really there, but it shouldn't affect
>>> your fs right now, unless you want to mount it with 64K page size.
>>>
>>> And for the new error (inline file extent too large), it may cause
>>> problems, but under most cases, kernel can handle it without problem.
>>>>
>>>> I'm still getting many errors.
>>>> Sorry I currently don't know what caused this. I suspect it might be
>>>> Seafile since I'm now having a currupted library there.
>>>>
>>>> Should I use --repair?
>>>
>>> No, --repair won't help in this case.
>>>
>>> In fact, your fs is fine, no on-disk metadata problem yet.
>>>
>>> For your case, I can only recommend to use newer kernel to have better
>>> sanity check.
>>> Meanwhile I would also recommend to run a memtest to ensure it's not
>>> some memory problem causing the bug.
>>>
>>> Thanks,
>>> Qu
>>>
>>>>
>>>> Regards
>>>> Mia
>>>>
>>>> ------ Originalnachricht ------
>>>> Von: "Qu Wenruo" <quwenruo.btrfs@gmx.com>
>>>> An: "Qu Wenruo" <wqu@suse.com>; "Mia" <9speysdx24@kr33.de>;
>>>> linux-btrfs@vger.kernel.org
>>>> Gesendet: 25.10.2021 13:18:54
>>>> Betreff: Re: filesystem corrupt - error -117
>>>>
>>>>>
>>>>>
>>>>> On 2021/10/25 19:14, Qu Wenruo wrote:
>>>>>>
>>>>>>
>>>>>> On 2021/10/25 19:13, Mia wrote:
>>>>>>> Hi Qu,
>>>>>>>
>>>>>>> thanks for your response.
>>>>>>> Here the output of btrfs check:
>>>>>>> https://gist.github.com/lynara/1c613f7ec9448600f643a59d22c1efb2
>>>>>>
>>>>>> Unfortunately it's not full, and it's using an old btrfs-progs
>>>>>> which can
>>>>>> cause false alert.
>>>>>
>>>>> My bad, gist is folding the output.
>>>>>
>>>>> It shows no corruption for the extent tree, thus I guess the
>>>>> transaction
>>>>> abort has prevented COW from being broken.
>>>>>
>>>>>>
>>>>>> Please use latest btrfs-progs v5.14.2 to re-check.
>>>>>
>>>>> In that case, a newer btrfs-progs is only going to remove the false
>>>>> alerts.
>>>>>
>>>>> Any clue on the workload causing the abort?
>>>>>
>>>>> For now, I can only recommend to use newer kernel (v5.10+ I 
>>>>> guess?) to
>>>>> see if you can reproduce the problem.
>>>>>
>>>>> Thanks,
>>>>> Qu
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Qu
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Mia
>>>>>>>
>>>>>>> ------ Originalnachricht ------
>>>>>>> Von: "Qu Wenruo" <quwenruo.btrfs@gmx.com>
>>>>>>> An: "Mia" <9speysdx24@kr33.de>; linux-btrfs@vger.kernel.org
>>>>>>> Gesendet: 25.10.2021 12:55:46
>>>>>>> Betreff: Re: filesystem corrupt - error -117
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2021/10/25 18:53, Qu Wenruo wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2021/10/25 16:46, Mia wrote:
>>>>>>>>>> Hello,
>>>>>>>>>> I need support since my root filesystem just went readonly :(
>>>>>>>>>>
>>>>>>>>>> [641955.981560] BTRFS error (device sda3): tree block 
>>>>>>>>>> 342685007872
>>>>>>>>>> owner
>>>>>>>>>> 7 already locked by pid=8099, extent tree corruption detected
>>>>>>>>>
>>>>>>>>> This line explains itself.
>>>>>>>>>
>>>>>>>>> Your extent tree is no corrupted, thus it allocated a new tree
>>>>>>>>> block
>>>>>>>>
>>>>>>>> I missed the "w" for the word "now"...
>>>>>>>>
>>>>>>>>> which is in fact already hold by other tree.
>>>>>>>>>
>>>>>>>>> This means your metadata is no longer protected properly by COW.
>>>>>>>>>
>>>>>>>>> "btrfs check" is highly recommended to expose the root cause.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> root@rx1 ~ # btrfs fi show
>>>>>>>>>> Label: none  uuid: 21306973-6bf3-4877-9543-633d472dcb46
>>>>>>>>>>      Total devices 1 FS bytes used 189.12GiB
>>>>>>>>>>      devid    1 size 319.00GiB used 199.08GiB path /dev/sda3
>>>>>>>>>>
>>>>>>>>>> root@rx1 ~ # btrfs fi df /
>>>>>>>>>> Data, single: total=194.89GiB, used=187.46GiB
>>>>>>>>>> System, single: total=32.00MiB, used=48.00KiB
>>>>>>>>>> Metadata, single: total=4.16GiB, used=1.65GiB
>>>>>>>>>> GlobalReserve, single: total=380.45MiB, used=0.00B
>>>>>>>>>>
>>>>>>>>>> root@rx1 ~ # btrfs --version
>>>>>>>>>> :(
>>>>>>>>>> btrfs-progs v4.20.1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> root@rx1 ~ # uname -a
>>>>>>>>>> Linux rx1 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18)
>>>>>>>>>> x86_64
>>>>>>>>>> GNU/Linux
>>>>>>>>>
>>>>>>>>> This is a little old for btrfs, but I don't think that's the 
>>>>>>>>> cause.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Qu
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hope someone can help.
>>>>>>>>>> Regrads
>>>>>>>>>> Mia
>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 25205 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]