Re: [BUG] BTRFS critical corrupt leaf - bisected to 496245cac57e

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

[-- Attachment #1.1: Type: text/plain, Size: 2360 bytes --]



On 2019/7/14 下午11:40, Chris Murphy wrote:
> On Sun, Jul 14, 2019 at 3:49 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>> I totally understand that the solution I'm going to provide sounds
>> aweful, but I'd recommend to use a newer enough kernel but without that
>> check, to copy all the data to another btrfs fs.
>>
>> It could be more safe than waiting for a btrfs check to repair it.
> 
> Does the problem affect all trees? If so, then merely creating new
> subvolumes, and then 'cp -a --relink oldsubvol newsubvol', and then
> delete old subvolumes, won't fix it.

Not 100% sure yet, but from your dump, it's affecting INODE_ITEM and
DIR_INDEX/DIR_ITEM.

For other trees, only root tree and data reloc tree has INODE_ITEM.
They may get affected but shouldn't be a problem.

> 
> I wonder where the ideas are for online or even out of band fsck.
> Offline fsck is too slow and does not scale, a known problem. And both
> copying old file system to new file system; as well as restoring
> backups to a new file system, is astronomically slower because data
> must also be copied, not just metadata. Also a known problem.
> 
> What about a variation on btrfs send/receive with --no-data option, to
> read out all the old metadata and rewrite all new metadata to the same
> file system, taking advantage of COW, but without having to copy out
> the data? And then after all of that is done, delete the old file
> subvolumes?

It looks possible, but the use case also looks very limited.
Just the case you're hitting, not a generic use case.

So I'm afraid it won't be possible in short term.

Thanks,
Qu

> 
> Or a variation on seed/sprout, without requiring additional devices.
> The seed part "snapshots" the whole original file system (all trees),
> and create two read-write file systems: current online mounted volume,
> and in-progress offline repair volume. If the repair fails, it's
> straightforward to clean up everything while retaining the changes -
> at least it's not worse off. If the repair succeeds, then there'd need
> to be some means of merging the two read-write file systems - that
> could be complicated. But even if in the short term that merge
> required an unmount, and perform the merge offline, that would be way
> more tolerable than the way things are now.
> 
> 


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