Re: pvmove thin volume doesn't move

> If the tool would have known 'which areas' are=C2=A0 mapped=C2=A0 (which =
knows thin-pool=20
> target internally) then it would need to copy only those blocks.

no doubt. but if lvmthin is basically a private implementation that LVM (ak=
a thick) doesn't actually know anything about and is just being used as a p=
ass-thru to thin API, I'm not sure we want to expose thin internals to the =
caller. I obviously haven't read the code implementing either thick or thin=
, but if thick does a thin_read(one 4MB extent) then thin should just retur=
n a buffer with 4mb populated with all the data converted into a thick+line=
ar representation that Thick is expecting. Then the traditional workflow ca=
n resume with the extent written out to its destination PV. In other words =
you're hydrating a thin representation into a thick representation. Could y=
ou take that buffer and thin_write(dest thin pool)? I don't see why not.

Or you could just punt and say pvmove() of a thin is necessarily a hydrate =
operation and can only be written out into a non-then PV, tough luck. Use o=
ffline `dd`if you want more.

I haven't been particularly impressed by LVM caching (it has it's uses don'=
t get me wrong) but I find layering open-cas to be more intuitive and gives=
 me a degree of freedom.