Reducing size of thin spare metadata, thin metadata

Reducing size of thin spare metadata, thin metadata

[Patrik Horník]

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?

Thanks.

Patrik

Re: Reducing size of thin spare metadata, thin metadata

[Zdenek Kabelac]

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.

You could also reduce size of thin pool metadata in case it's too big, just 
not online.


With offline thinpool with these manual steps
(will be later automated with tool as well):

--

make a temporary LV of any size.
swap this temp LV with  pool metadata

# lvconvert --thinpool  vg/mypool   --poolmetadata mytemplv

Create your volume for metadata with new reduced size
(unsure which size is your target - but some calcs based on estimated usage 
are necessary)

Activate   mytemplv  which has now real metadata from thinpool.

# thin_repair  -i /dev/vg/mytemplv   -o /dev/vg/mynewsizemeta

# thin_check  /dev/vg/mynewsizemeta


If all is green - swap new meta into your thinpool

# lvconvert --thinpool  vg/mypool   --poolmetadata mynewsizemeta


If all works great you are done :)
In all other cases you have your backup at hand :)

Yeah - you still have old metadata in mytemplv - this volume you may remove
later if all works well - otherwise you may try to swap this volume back.

Zdenek

Re: Reducing size of thin spare metadata, thin metadata

[Patrik Horník]

Hi,

2014-10-06 9:39 GMT+02:00 Zdenek Kabelac <zkabelac@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.)

> You could also reduce size of thin pool metadata in case it's too big, just
> not online.
>
>
> With offline thinpool with these manual steps
> (will be later automated with tool as well):
>
> --
>
> make a temporary LV of any size.
> swap this temp LV with  pool metadata
>
> # lvconvert --thinpool  vg/mypool   --poolmetadata mytemplv
>

Does not lvconvert only change metadata volume not copying data to it?
So isn't there missing step to copy metadata from current metadata to
mytemplv? Why do u use mytemplv anyway and dont copy metadata directly
from current metadata to new smaller LV?

Anyway I prefer to reduce spare metadata if possible and not risk
reducing real metadata, it should be enough for me.

Thanks.

Patrik

> Create your volume for metadata with new reduced size
> (unsure which size is your target - but some calcs based on estimated usage
> are necessary)
>
> Activate   mytemplv  which has now real metadata from thinpool.
>
> # thin_repair  -i /dev/vg/mytemplv   -o /dev/vg/mynewsizemeta
>
> # thin_check  /dev/vg/mynewsizemeta
>
>
> If all is green - swap new meta into your thinpool
>
> # lvconvert --thinpool  vg/mypool   --poolmetadata mynewsizemeta
>
>
> If all works great you are done :)
> In all other cases you have your backup at hand :)
>
> Yeah - you still have old metadata in mytemplv - this volume you may remove
> later if all works well - otherwise you may try to swap this volume back.
>
> Zdenek
>

Re: Reducing size of thin spare metadata, thin metadata

[Zdenek Kabelac]

Dne 6.10.2014 v 09:59 Patrik Horník napsal(a):
> Hi,
>
> 2014-10-06 9:39 GMT+02:00 Zdenek Kabelac <zkabelac@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

Re: 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@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@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
>

Re: Reducing size of thin spare metadata, thin metadata

[Zdenek Kabelac]

Dne 6.10.2014 v 10:12 Patrik Horník napsal(a):
> 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?
>

Idea behind spare is to have 'reserved' space for pool metadata recovery.
(it's like hidden space in filesystem)

When the pool gets broken and you don't have reserved space for repair
you need to add new free space for recovery.

And at this moment it's getting quite complex (well beyond autonomous 
'lvconvert --repair').

So as long as you know what you are doing and you could repair
metadata manually - you are fine.
(You could disable creation of spare volume in lvm.conf)

But lvm2 requires to have reserved space to proceed for --repair.
After all - the size of pool metadata should be pretty small compared with the 
rest of VG.

Zdenek

Re: Reducing size of thin spare metadata, thin metadata

[Patrik Horník]

Thanks Zdenku. But you did not answer some of my questions, which I
need to know to decide... So is there a way I can create smaller spare
metadata LV? In mentioned manual steps what do I need mytemplv for and
why cant I use original pool metadata as input of thin_repair?

Thanks.

2014-10-06 10:31 GMT+02:00 Zdenek Kabelac <zkabelac@redhat.com>:
> Dne 6.10.2014 v 10:12 Patrik Horník napsal(a):
>>
>> 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?
>>
>
> Idea behind spare is to have 'reserved' space for pool metadata recovery.
> (it's like hidden space in filesystem)
>
> When the pool gets broken and you don't have reserved space for repair
> you need to add new free space for recovery.
>
> And at this moment it's getting quite complex (well beyond autonomous
> 'lvconvert --repair').
>
> So as long as you know what you are doing and you could repair
> metadata manually - you are fine.
> (You could disable creation of spare volume in lvm.conf)
>
> But lvm2 requires to have reserved space to proceed for --repair.
> After all - the size of pool metadata should be pretty small compared with
> the rest of VG.
>
> Zdenek
>

Re: Reducing size of thin spare metadata, thin metadata

[Zdenek Kabelac]

Dne 6.10.2014 v 10:48 Patrik Horník napsal(a):
> Thanks Zdenku. But you did not answer some of my questions, which I
> need to know to decide... So is there a way I can create smaller spare
> metadata LV? In mentioned manual steps what do I need mytemplv for and
> why cant I use original pool metadata as input of thin_repair?

Spare volume is maintained to have the size at least as the biggest
pool metadata volume in VG.

There is no point to keep smaller reserved space.

We do not allow to activate 'subvolumes' - thus you cannot activate
just 'thin pool metadata'  - that's why you need to swap _tmeta
out thin pool.

Zdenek

Fwd: Reducing size of thin spare metadata, thin metadata

[Patrik Horník]

Thank you very much, now I understand.

But apparently I dont understand exact function of " lvconvert
--thinpool  vg/mypool   --poolmetadata mytemplv" So it also copies
metadata from current metadata LV to mytemplv?

Then what about "lvconvert --thinpool  vg/mypool   --poolmetadata
mynewsizemeta"? It does not do that because mynewsizemeta is smaller
than current metadata mytemplv or?


2014-10-06 10:57 GMT+02:00 Zdenek Kabelac <zkabelac@redhat.com>:
> Dne 6.10.2014 v 10:48 Patrik Horník napsal(a):
>>
>> Thanks Zdenku. But you did not answer some of my questions, which I
>> need to know to decide... So is there a way I can create smaller spare
>> metadata LV? In mentioned manual steps what do I need mytemplv for and
>> why cant I use original pool metadata as input of thin_repair?
>
>
> Spare volume is maintained to have the size at least as the biggest
> pool metadata volume in VG.
>
> There is no point to keep smaller reserved space.
>
> We do not allow to activate 'subvolumes' - thus you cannot activate
> just 'thin pool metadata'  - that's why you need to swap _tmeta
> out thin pool.
>
> Zdenek
>

Re: Fwd: Reducing size of thin spare metadata, thin metadata

[Marian Csontos]

On 10/06/2014 11:05 AM, Patrik Horník wrote:
> Thank you very much, now I understand.
>
> But apparently I dont understand exact function of " lvconvert
> --thinpool  vg/mypool   --poolmetadata mytemplv" So it also copies
> metadata from current metadata LV to mytemplv?

Nope, the metadata are copied by `thin_repair` step:

# thin_repair  -i /dev/vg/mytemplv   -o /dev/vg/mynewsizemeta

The lvconvert "only" swaps LVs.

-- Martian

>
> Then what about "lvconvert --thinpool  vg/mypool   --poolmetadata
> mynewsizemeta"? It does not do that because mynewsizemeta is smaller
> than current metadata mytemplv or?
>
>
> 2014-10-06 10:57 GMT+02:00 Zdenek Kabelac <zkabelac@redhat.com>:
>> Dne 6.10.2014 v 10:48 Patrik Horník napsal(a):
>>>
>>> Thanks Zdenku. But you did not answer some of my questions, which I
>>> need to know to decide... So is there a way I can create smaller spare
>>> metadata LV? In mentioned manual steps what do I need mytemplv for and
>>> why cant I use original pool metadata as input of thin_repair?
>>
>>
>> Spare volume is maintained to have the size at least as the biggest
>> pool metadata volume in VG.
>>
>> There is no point to keep smaller reserved space.
>>
>> We do not allow to activate 'subvolumes' - thus you cannot activate
>> just 'thin pool metadata'  - that's why you need to swap _tmeta
>> out thin pool.
>>
>> Zdenek
>>
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>