> IIRC you get a HEALTH_WARN message that there are OSDs with old metadata
> format. You can suppress that warning, but I guess operators feel like
> they want to deal with the situation and get it fixed rather than ignore it.
Yes, and if suppress the waning gets forgotten you run into other
issue
Am Di., 9. Nov. 2021 um 11:08 Uhr schrieb Dan van der Ster
:
>
> Hi Ansgar,
>
> To clarify the messaging or docs, could you say where you learned that
> you should enable the bluestore_fsck_quick_fix_on_mount setting? Is
> that documented somewhere, or did you have it enabled from previously?
> Th
On Tue, Nov 9, 2021 at 11:29 AM Stefan Kooman wrote:
>
> On 11/9/21 11:07, Dan van der Ster wrote:
> > Hi Ansgar,
> >
> > To clarify the messaging or docs, could you say where you learned that
> > you should enable the bluestore_fsck_quick_fix_on_mount setting? Is
> > that documented somewhere, or
Hi Ansgar,
I've submitted the following PR to recover broken OMAPs:
https://github.com/ceph/ceph/pull/43820
One needs a custom build for now to use it though. And this might be a
bit risky to apply since this hasn't passed all the QA procedures...
For now I'm aware about one success and one
Hi Ansgar,
To clarify the messaging or docs, could you say where you learned that
you should enable the bluestore_fsck_quick_fix_on_mount setting? Is
that documented somewhere, or did you have it enabled from previously?
The default is false so the corruption only occurs when users actively
choose
> > I did an upgrade from 14.2.23 to 16.2.6 not knowing that the current
> > minor version had this nasty bug! [1] [2]
>
> I'm sorry you hit this bug. We tried to warn users through
> documentation. Apparently this is not enough and other ways of informing
> operators about such (rare) incidents m
