linux-kernel - Re: [6.2][regression] after commit 947a629988f191807d2d22ba63ae18259bb645c5 btrfs volume periodical forced switch to readonly after a lot of disk writes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52793f07-a842-dac0-b7c2-bca641e18a94@gmx.com>
Date:   Thu, 29 Dec 2022 08:00:11 +0800
From:   Qu Wenruo <quwenruo.btrfs@....com>
To:     Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
Cc:     Qu Wenruo <wqu@...e.com>, dsterba@...e.com,
        Btrfs BTRFS <linux-btrfs@...r.kernel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: Re: [6.2][regression] after commit
 947a629988f191807d2d22ba63ae18259bb645c5 btrfs volume periodical forced
 switch to readonly after a lot of disk writes



On 2022/12/29 07:42, Mikhail Gavrilov wrote:
> On Thu, Dec 29, 2022 at 4:24 AM Qu Wenruo <quwenruo.btrfs@....com> wrote:
>>
>> Just one last thing to confirm, mind to provide the following dump?
>>
>>    # btrfs ins dump-tree -t chunk <device>
>>
>> If the fix works, it means you have some tree block crossing stripe
>> boundary, which is not the ideal situation.
> 
> I attached this dump.
> The only thing that I did from a working system I hope it is not
> affected to result?
> 
For small dumps like chunk tree, it's completely fine to dump from live 
systems.

And your dumps (along with your previous debug output) shows no metadata 
crossing stripe boundaries.

I'd need dig deeper why btrfs is splitting extent buffers unnecessarily.

Thanks,
Qu