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.
