Re: pvmove thin volume doesn't move

Dne 19. 11. 25 v 17:36 Brian J. Murrell napsal(a):
>> 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.

Ok - now I start to see - where we need to enhance our documentation.

So here - 'adding' different space to thin-pool wouldn't not be a good idea.
We will likely need to add at least 'prompt' protection if user would try to 
extend  'hdd'  based LV used for thin-pool data with i.e. non-rotational
(we are in planning phase for new allocation - which will be dealing with this 
- but we should add some protection to existing code base).

thin-pool does it's own decision where it allocates 'chunks' for thin LV and 
for thin-pool itself given space is 'one big device'


> 
>> 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.
> 

Ok - I'll try to add more details about 'virtual LVs' - which are thinLVs and 
vdoLVs  (and we have even combination of both)

Here we surely can add more disclaimers about the major difference between 
virtual and real LVs.


>> 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.

We surely always try to add the best details we can.
But there is also some 'expectancy' user is somewhat knowledgeable.
The performance of thin-pool ain't for free - so there are some drawbacks when 
user settles with thin-pools.

> 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.

Like our error messaging - in case it makes no good explanation to the user 
should be always reported and requested for enhancement.

Regards

Zdenek