[linux-lvm] Still missing for supporting dm-thin

[linux-lvm] Still missing for supporting dm-thin

[Spelic]

Hello all,
thanks for your hard work in supporting dm-thin from LVM

There are still 2 important features missing that I noticed when I tried it:

1) It is not possible to backup and restore a VG config (vgcfgrestore in 
particular refuses to work) if there is a dm-thin volume. This is a very 
serious problem that does not allow to recover even non-thin volumes if 
there is a thin volume around. Even automatic backups from 
/etc/lvm/archive cannot be restored/used. This puts data at risk, please 
fix this.

2) less important: it is apparently not possible to change the --zero 
flag for a thin pool once created. This is a quite important flag that 
should be tweakable IMHO... however if #1 is fixed, one could backup the 
config, modify the flag, and restore the config to achieve that.

Thanks for your work
S.

Re: [linux-lvm] Still missing for supporting dm-thin

[Alasdair G Kergon]

On Mon, Jun 25, 2012 at 04:34:52PM +0200, Spelic wrote:
> 1) It is not possible to backup and restore a VG config (vgcfgrestore in  
> particular refuses to work) if there is a dm-thin volume. This is a very  
> serious problem that does not allow to recover even non-thin volumes if  
> there is a thin volume around. Even automatic backups from  
> /etc/lvm/archive cannot be restored/used. This puts data at risk, please  
> fix this.

We do want to find a way to do this for non-thin volumes - the current 
restrictions are indeed tighter than they need to be.

For thin volumes though it's a complex problem to work out what can
be restored safely and what can't.  (The metadata saying where a volume is is
now split between the LVM metadata and the thin metadata.)

> 2) less important: it is apparently not possible to change the --zero  
> flag for a thin pool once created. 

That should be just another lvchange parameter.

Alasdair

Re: [linux-lvm] Still missing for supporting dm-thin

[Zdenek Kabelac]

Dne 25.6.2012 18:27, Alasdair G Kergon napsal(a):
> On Mon, Jun 25, 2012 at 04:34:52PM +0200, Spelic wrote:
>> 1) It is not possible to backup and restore a VG config (vgcfgrestore in
>> particular refuses to work) if there is a dm-thin volume. This is a very
>> serious problem that does not allow to recover even non-thin volumes if
>> there is a thin volume around. Even automatic backups from
>> /etc/lvm/archive cannot be restored/used. This puts data at risk, please
>> fix this.
>
> We do want to find a way to do this for non-thin volumes - the current
> restrictions are indeed tighter than they need to be.
>
> For thin volumes though it's a complex problem to work out what can
> be restored safely and what can't.  (The metadata saying where a volume is is
> now split between the LVM metadata and the thin metadata.)

We need history also for all LVs used by thin-pool - so currently the safest
is to disable restore until we are sure we could provide some solution, where 
the user does not easily break whole VG in non-repairable way.

>
>> 2) less important: it is apparently not possible to change the --zero
>> flag for a thin pool once created.
>
> That should be just another lvchange parameter.
>


While going from  --zero mode to non zero is quite ok, the opposite direction 
might have unexpected side effects.

If the block were provisioned in the non-zero mode - they may have random pool 
content on unwritten data areas - thus if user may arbitrarily switch between 
zeroing type - the content would be unpredictable, and we would need to keep 
this as some history flag - once the pool was started without zeroing,
we may not guarantee, provisioned unwritten data blocks will have zero 
content.  So for full support we have to make clear, how we will keep history 
info - i.e. to avoid bugreports where the weird data will be received in the 
zero mode.  (something like tainted kernel ?)

It is getting even more complex when I play with discard options...

Zdenek

Re: [linux-lvm] Still missing for supporting dm-thin

[Spelic]

On 06/26/12 11:11, Zdenek Kabelac wrote:
> Dne 25.6.2012 18:27, Alasdair G Kergon napsal(a):
>>
>> We do want to find a way to do this for non-thin volumes - the current
>> restrictions are indeed tighter than they need to be.
>>
>> For thin volumes though it's a complex problem to work out what can
>> be restored safely and what can't.  (The metadata saying where a 
>> volume is is
>> now split between the LVM metadata and the thin metadata.)
>
> We need history also for all LVs used by thin-pool - so currently the 
> safest
> is to disable restore until we are sure we could provide some 
> solution, where the user does not easily break whole VG in 
> non-repairable way.
>

Setting everything artificially as non-repairable is imho worse than 
allowing the user to repair something.
I don't know about the history problem you mention, however, why don't 
you put a warning and ask for confirmation to the user, to proceed and 
repair at least the non-thin volumes? Maybe give details about the 
history problem you mentioned and ask for confirmation.

As a temporary workaround I was thinking about creating an LV for thin 
use, which contains a PV for a new VG where the thin pools and volumes 
are inside. That would allow me to repair at least the non-thin volumes, 
wouldn't it?


>>
>>> 2) less important: it is apparently not possible to change the --zero
>>> flag for a thin pool once created.
>>
>> That should be just another lvchange parameter.
>>
>
>
> While going from  --zero mode to non zero is quite ok, the opposite 
> direction might have unexpected side effects.
>
> If the block were provisioned in the non-zero mode - they may have 
> random pool content on unwritten data areas - thus if user may 
> arbitrarily switch between zeroing type - the content would be 
> unpredictable, and we would need to keep this as some history flag - 
> once the pool was started without zeroing,
> we may not guarantee, provisioned unwritten data blocks will have zero 
> content.  So for full support we have to make clear, how we will keep 
> history info - i.e. to avoid bugreports where the weird data will be 
> received in the zero mode.  (something like tainted kernel ?)
>

I think that users willing to switch between the two should be aware of 
the problems. I'd suggest putting that as a warning or in the manpage 
but don't disallow us the zero switching.


> It is getting even more complex when I play with discard options...

This one I don't understand. It's true then! I think I need to read the 
warning you will put :-)

Thank you