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

[Chris Murphy <lists@colorremedies.com>]

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.

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?

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.


-- 
Chris Murphy