Still missing for supporting dm-thin
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.
Quoted 6 lines · Spelic
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/archivecannot 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.)
Quoted 2 lines
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
Dne 25.6.2012 18:27, Alasdair G Kergon napsal(a):
Quoted 8 lines · Spelic
Quoted 6 lines
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/archivecannot be restored/used. This puts data at risk, please fix this.
Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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
Quoted 5 lines · Zdenek Kabelac
Dne 25.6.2012 18:27, Alasdair G Kergon napsal(a):
Quoted 4 lines
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.
Quoted 7 lines
Quoted 3 lines
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?
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
2) less important: it is apparently not possible to change the --zero flag for a thin pool once created.
Quoted 9 lines
Quoted 2 lines
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.
Quoted 1 line
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