Re: [PATCH] btrfs: Introduce new mount option to skip block group items scan

[David Sterba <dsterba@suse.cz>]

On Thu, Dec 20, 2018 at 04:01:37PM +0800, Qu Wenruo wrote:
> Btrfs needs to read out all block group (bg) items to fill its bg
> caches.
> 
> However such bg caches are only needed for read-write mount, and makes
> no sense for RO mount.
> 
> So this patch introduce new mount option, skip_bg, to skip block group
> items scan.
> 
> This new 'skip_bg' mount option can only be used with TRUE read-only
> mount, which needs the following dependency:
> - RO mount
>   Obviously.
> 
> - No log tree or notreelog mount option
> 
> - No way to remoutn RW
>   Similar to notreelog mount option.
> 
> - No chunk <-> bg <-> dev extents restrict check
> 
> This option should only be used as kernel equivalent of btrfs-restore.
> 
> With this patch, we can even mount a btrfs whose extent root is
> completely corrupted.

So it's a last-resort rescue option, I'd suggest to make that more
explicit. Something like rescue=skip-bg. We can add all sorts of other
values that would relax some checks. Adding a separate mount option
would be quite impractical.

This would also align with the constraints you mention above, eg. no way
to remount RW. This is fine for the corrupted extent root. I wonder what
kind of metadata damage support would still make sense. a 'completely
corrupted extent root' means you never know what you get from the
filesystem.

The in-kernel checks and interconnection of the structures would have to
be ready for missing metadata or more sanity checks would need to be
added.

I think that all the restore and rescue functionality is better suited
for userspace where the unpredictable corruptions that cannot be parsed
do not lead to kernel crashes or silent memory overwrites.

> But can also be an option to test if btrfs_read_block_groups() is the
> major cause for slow btrfs mount.

We have a debugging/testing -only mount option 'fragment', so we may
consider adding more.