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