Dne 19. 11. 25 v 15:07 Matthew Patton napsal(a):
<quote>
Usually once user goes with thin-pools - it's decision taken with knowledge
that the only way out is to take out whole data out of thin-pool and copy them
to the new place
</quote>
That is one hell of a wild and unsupported assumption. Practically nobody ,
even seasoned sysadmins would know of this deficiency. Does the lvm(1) manage
splatter this warning prominently?
Pretty sure the HP/ux and IBM implementations support thin movement.
Well I've no idea which volume managers you are talking about, all I say is -
lvm2 ATM does not support any sort of 'extraction' of a thinLV out of the
thin-pool. The main benefit of using 'thin-pool' is the you share storage
between volumes.
As far as for documentation - I'm pretty sure we never mentioned any support
of such operation within our lvm2 man pages.
And the initial lines in our 'man lvmthin' explicitly states this:
----
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.
----
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)
Regards
Zdenek