On 2019/7/29 下午9:42, Swâmi Petaramesh wrote:
>
> Le 29/07/2019 à 15:35, Qu Wenruo a écrit :
>> This means btrfs metadata CoW is broken.
>
> I remember having had exactly the same kind of messages on the main
> machine's SSD a week ago (before I had to recreate, backup and restore it)
>
>> Did the system went through some power loss?
>
> No *THIS* filesystem is an external backup. It's typical use is plug,
> backup, umount (properly), unplug.
>
> So there's very little reasons such a filsystem would en up broken.
>
>> If not, then it's btrfs or lower layer causing the problem.
>>
>> Did you have any btrfs without LUKS?
>
> Not much...
>
> Here's the rest of the (still running) btrsf check :
>
> # btrfs check /dev/mapper/luks-UUID
> Opening filesystem to check...
> Checking filesystem on /dev/mapper/luks-UUID
> UUID: ==somehing==
> [1/7] checking root items
> [2/7] checking extents
> parent transid verify failed on 2137144377344 wanted 7684 found 7499
> parent transid verify failed on 2137144377344 wanted 7684 found 7499
> parent transid verify failed on 2137144377344 wanted 7684 found 7499
> Ignoring transid failure
> leaf parent key incorrect 2137144377344
> bad block 2137144377344
All these are the same problem, one tree block didn't went through CoW,
and overwritten some existing data.>
>
> Uh I'm at a loss...
Although there are some bug fixes queued for stable, it doesn't look
like related to such CoW breakage.
Thus we need to rule out lower layer bugs to make sure it's btrfs
causing the problem.
Thanks,
Qu
>
> ॐ
>
