Re: corrupt leaf, invalid data ref objectid value, read time tree block corruption detected Inbox

[Nicholas D Steeves <sten@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]

Qu Wenruo <quwenruo.btrfs@gmx.com> writes:

> 在 2024/11/27 09:39, Brett Dikeman 写道:
>> On Tue, Nov 26, 2024 at 4:30 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>> Inode cache is what you need to clear.
>>
>> Brilliant! Thank you, Qu. It did mount cleanly. Shame Debian's
>> toolchain is so out-of-date. I pinged the maintainer asking if they
>> could pull 6.11.
>>
>> Is there anything I could have done that would have caused the
>> corrupted inode cache?
>
> It's not corrupted, but us deprecating that feature quite some time ago.
> And then a recently enhanced sanity check just treat such long
> deprecated feature as an error, thus rejecting those tree blocks.
>
>>
>> 'btrfs check' thought the second drive was busy after unmounting, but
>> a reboot cured that.
>>
>> check found the following; Is the fix for this to clear the free space cache?
>
> I'd recommend to go v2 cache directly.
>
> You may not want to hear, but we're going to deprecate v1 cache too.
>
> V2 cache has way better crash handling, I have not yet seen a corrupted
> v2 cache yet.

Let's avoid a "btrfs is the only fs that ate my data" storm.  Would it
be sufficient to provide free space cache v2 migration instructions in
our release notes?  If not, would you be willing to write something?
Alternatively, should this be automatic, and in-kernel?  Debian users
tend to have long-running installations and don't tend to reinstall.  I
think you'll agree we ought to get ahead of the thousands of users who
have v1 cache and who ran mkfs with btrfs-progs as early as 4.4 or 4.9.

Most users will migrate from a recent 6.1.x (close to kernel.org's)
directly to 6.12.x (what seems to be the most likely LTS).  Many have
also tracked the stable mainline or have recently upgraded to 6.11.

Beyond that, I'm not aware of any format chances (other than some new
experimental raid56 stuff), but it might also be nice to know if there's
a threshold where it would be better to reformat an "aged" filesystem.


Kind regards,
Nicholas

P.S. We'll fix the ancient btrfs-progs problem before the new year.  The
current issue is where "strong package ownership" processes slow things
down.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]