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
