On Mon, Oct 24, 2022 at 03:08:21PM +0800, Qu Wenruo wrote:
>
>
> On 2022/10/16 20:24, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
> >
> > The patch below does not apply to the 5.10-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@xxxxxxxxxxxxxxx>.
> >
> > Possible dependencies:
> >
> > 81d5d61454c3 ("btrfs: enhance unsupported compat RO flags handling")
> > dfe8aec4520b ("btrfs: add a btrfs_block_group_root() helper")
> > b6e9f16c5fda ("btrfs: replace open coded while loop with proper construct")
> > 42437a6386ff ("btrfs: introduce mount option rescue=ignorebadroots")
>
> Hi Greg and btrfs guys,
>
> I'm not confident enough to continue backporting this patch (and its
> dependency) for older branches.
>
> This patch itself relies on the new function fill_dummy_bgs() to skip the
> full block group items search.
>
> That function is the core functionality to allow us to mount fses read-only
> with unsupported compat_ro flags.
>
> But if we backport 42437a6386ff ("btrfs: introduce mount option
> rescue=ignorebadroots"), we need the "rescue=" mount option series, which
> can be super large, especially for older and older branches.
>
> The other solution is to still implement that fill_dummy_bgs(), but not
> introducing the "rescue=" mount option.
> This means, we will have some moderate changes to 42437a6386ff ("btrfs:
> introduce mount option rescue=ignorebadroots"), but at least no full
> dependency on the "rescue=" mount options.
>
> I'm wondering which solution would be more acceptable from the POV of stable
> kernels?
First off, is this really needed in older kernels? It was marked as
such, but that's up to you all to decide if it's true or not.
So I'll defer to you and the btrfs maintainers on what to do, just let
us know.
thanks,
greg k-h
