Re: corruption after block-group-tree conversion, how to recover? (data is readable)

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

在 2026/4/27 12:13, Thomas Debesse 写道:
> Le lun. 27 avr. 2026 à 00:18, Qu Wenruo <wqu@suse.com> a écrit :
>> Unfortunately, transid mismatch is not reliably repairable.
>> I'm afraid restoring from backup is the only reliable solution.
> 
> Thank you for your answers. Is the data from the “badly converted”
> volume be assumed safe?

If you really want to know that, only a full "btrfs check" can give you 
some clue.

The transid mismatch means the block group tree block is being 
over-written by some other tree blocks.

It can be minor, e.g. over-written by a new bg tree block, or it can 
cause data loss, e.g. over-written by a subvolume tree.

And it can even be worse, if there are multiple tree blocks being 
overwritten.


Your "rescue=all" mount working is a good indication that at least most 
of your subvolume trees are good, but it also disables datachecksum 
verification, so there is still a chance that csum tree is corrupted.


> 
> The idea is that, instead of overwriting the “badly converted” volume
> with a brand newly created and empty btrfs volume and copying the data
> from backup, I may consider the option to create the new btrfs volume
> on brand new devices I may source. I would have then the option to
> copy the data from either the backup or the “badly converted” volume.
> If the data is safely copyable from the “badly converted” volume (once
> mounted with recovery options), I expect copying from the “badly
> converted” volume to be way faster than copying from backup.

In that case, you may want to try this mount option instead:

"-o ro,rescue=ibadroots,nologreplay", which will allow btrfs to skip the 
bad block group tree, but still enables data checksum verification.

> 
> Also another question: if it happens that copying from the “badly
> converted” volume can be assumed to be safe, would `btrfs send` work
> or do I would still have to do it the btrfs-agnostic way, like by
> using rsync?

I think 'btrfs send' may work, but haven't yet verified.

> 
> Thanks in advance for your answers, that helps a lot.
> 

And I forgot to ask, when did the corruption happen?
Immediately after the conversion finished, or the first mount worked, 
but corruption happened later?

If immediately after a finished conversion, then it's very possible the 
conversion is the cause.

If not, then it may be something else, like the older non-upstream LTS 
kernel from Ubuntu.

The reason I'm asking is, although there are some fixes in progs v6.15, 
they are all addressing problems related to resuming interrupted conversion.
Thus I'm wondering what is the root cause of the transid mismatch.

Thanks,
Qu