Re: pvmove thin volume doesn't move

["Brian J. Murrell" <brian@interlinx.bc.ca>]

> lvm2  ATM does not support any sort of 'extraction' of a thinLV out
> of the 
> thin-pool.

Maybe that's an explanation that goes over my head with me not being an
LVM2 engineer but rather just a general jack-of-all-trades sysadmin.

But that said, I'm not sure what kind of operation "extraction" is
supposed to be implying but I suppose what I was thinking (hoping for,
now it seems) was that in order to be able to move the blocks of an LV
in a thin-pool from one PV to another one would of course have to
extend the thin-pool to the new device, in the same way that any LV can
span devices.

> The main benefit of using 'thin-pool' is the you share storage 
> between volumes.

And that snapshots of (thinly provisioned) LVs don't degrade
performance.

> As far as for documentation - I'm pretty sure we never mentioned any
> support 
> of such operation within our lvm2 man pages.

pvmove's manpage does describe the ability to move LVs among PVs. 
That, IMO, implies thin-LVs without any kind of disclaimer saying
otherwise.

> Blocks in a standard LV are allocated (during creation) from the
> Volume Group 
> (VG), but blocks in a thin LV  are  allocated  (during  use)
> from a "thin pool".  The thin pool contains blocks of physical
> storage, and 
> thin LV blocks reference blocks in the thin pool.

That sounds like a good description for an LVM2 software engineer
onboarding to thin provisioning.  I don't think that description is
suitable to express the limitations (that are becoming apparent in this
thread) to general jack-of-all-trades system administrators as it
implies more knowledge of LVM2 than such a person could/would generally
have IMO.

> Thin-pool is some sort of a black box from lvm2's POV - it serves
> volumes - 
> and lvm2 knows how to make those volumes available on the system -
> but the 
> mapping of chunks to make a thin LV as fully in hands of thin-pool
> target.
> lvm2 has 'no idea'  which disk space is in-use for any individual
> thin LV.
> (there are tools like 'thin_ls/thin_rmap' for that)

Again, much too technically detailed to express these limitations to a
general sysadmin that has to employ literally dozens of technologies in
one's administrative scope and therefore cannot possibly try understand
all of the underlying design decisions of every one of those dozens of
technologies.

Cheers,
b.