[linux-lvm] Check of pool ernie/cache failed (status:1). Manual repair required!

[Dennis Schridde]

On Wednesday, 23 May 2018 21:39:47 CEST Dennis Schridde wrote:
> On Wednesday, 16 May 2018 20:31:15 CEST Dennis Schridde wrote:
> > On Tuesday, 15 May 2018 13:15:55 CEST Zdenek Kabelac wrote:
> > > Dne 15.5.2018 v 10:11 Dennis Schridde napsal(a):
> > > To get direct access to metadata - you could use your latest lvm2
> > > 2.02.177
> > > build (or even 'git master'). In these recent versions there is added
> > > support to activate directly these 'subLVs'.  So with latest lvm2 you
> > > can:
> > > 
> > > lvchange -ay  vg/lv_cmeta
> > 
> > I tried that (using 2.02.177), but it does not work:
> > # lvchange -ay ernie/cache_cmeta
> > 
> >   Operation not permitted on hidden LV ernie/cache_cmeta.
> 
> Does anyone have a suggestion how I can activate this volume in order to
> extract the information Zdenek asked for?
> 
> For more context please see the start of this thread.  The gist is that my
> cached LV cannot be activated anymore, and `lvconvert --repair` reports:
> bad checksum in superblock
>   Repair of cache metadata volume of cache ernie/system failed (status:1).
> Manual repair required!
> 
> My most important questions are:
> * What is broken?
>   - What information does the superblock carry / what is its purpose?
>   - Where is it located / which part of my disk was damaged?
>   - What will be the consequence of it being irrecoverably lost?
> * What does "manual repair" mean in detail?
>   - Using a specific tool?
>   - Flipping bits using a hex editor?
> * Is there some way to recover the cache?  Or is it at least possible to
> uncache the LV forcibly, to hopefully recover the data on the origin LV?
> * What is your recommendation to minimise data loss?

How would I create a backup of the affected LVs, so that dangerous commands 
would not destroy the data and get me into an unrecoverable state?  Is that 
possible without activating the volumes?  Is it possible to force-activate the 
volumes, without changing the bits on the disk -- just so that I can read from 
the LV and create the backup?

--Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20180526/67bd74dd/attachment.sig>