[dm-devel] Reducing size of thin spare metadata, thin metadata

[Patrik Horník]

OK, I see. So the result is that pool is not activated when it does
not pass check and there is no spare? So is it totally safe to have no
spare?

And so is there a way to reduce size of spare / create spare of
specified (smaller) size after its removal?

2014-10-06 10:05 GMT+02:00 Zdenek Kabelac <zkabelac at redhat.com>:
> Dne 6.10.2014 v 09:59 Patrik Horník napsal(a):
>>
>> Hi,
>>
>> 2014-10-06 9:39 GMT+02:00 Zdenek Kabelac <zkabelac at redhat.com>:
>>>
>>> Dne 6.10.2014 v 09:28 Patrik Horník napsal(a):
>>>
>>>> Hi,
>>>>
>>>> is it possible to (safely) reduce size of thin metadata and / or thin
>>>> spare metadata? What size of spare metadata is needed? Can it be
>>>> smaller than size of pool metadata?
>>>>
>>>
>>> You could remove pool spare volume anytime  - lvremove.
>>> (it's only used for automated lvconvert --repair)
>>>
>>> Repair needs free space in VG - if there is no free space - well tool
>>> can't
>>> be used.
>>
>>
>> when does automated lvconvert --repair kick in? Can I do it manually
>> if it cannot continue automatically? (I actually have space for spare
>> metadata so I want it there if it useful but smaller. I only need to
>> decrease size of my volume group by couple of 100s MB because of
>> moving to new device. My spare is 8 GB as is regular metadata.)
>
>
> When thin-pool does not pass 'thin-check' during thin-pool activation,
> you could try to use this  'lvconvert --repair' at first.
>
> Basically it automates steps described in previous mail - except it will try
> to use bigger 'replaceable' LV.
>
> Yet the functionality is not really any better then that - it's still
> missing
> many validation checks between user-land lvm2 metadata and kernel-land
> thin-pool metadata.
>
> But it's being improved.
> Meanwhile any 'major' damage of thin-pool metadata do need  'hand' work
> repair - since human can do far better decision then this initial
> implementation.
>
> Also note - any pool damage is still important to be reported - as
> thin pool metadata should be nearly impossible to break in the first place
> ;)
>
> Zdenek
>