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
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
