On Tue, Feb 02, 2016 at 11:14:01AM -0500, John Ferlan wrote:
On 02/02/2016 08:30 AM, Pavel Hrdina wrote:
> On Tue, Feb 02, 2016 at 09:11:51AM +0100, Ján Tomko wrote:
>> On Mon, Feb 01, 2016 at 03:29:53PM -0500, John Ferlan wrote:
>>> Modify the regex for the 'devices' (a/k/a 'extents') from
"(\\S+)"
>>> (e.g., 1 or more) to "(\\S*)" (e.g., zero or more).
>>>
>>> Then for any "thin" lv's found, mark the volume as a sparse
volume so
>>> that the volume wipe algorithm doesn't work.
>>>
>>> Since a "thin" segtype has no devices, this will result in any
"thin"
>>> lv part of some thin-pool within a volume group used as a libvirt pool
>>> to be displayed as a possible volume to use.
>>>
>>
>> A thin pool is another layer on top of some of the LVs in the VG.
>> I think it deserves a separate pool type.
>
> I must agree with Jan, and also already wrote the same for v2 patch. The thin
> pool and thin LV shouldn't be mixed with normal logical pool even they share
the
> same VG.
>
If LVM allows it, then who are we to say it cannot or shouldn't work or
how it should be configured?
Even if they are mixed in the same VG, we could show the "thick" LVs
in the type='logical' pool and the thin ones in type='thin'.
Thin pools were introduced in LVM2
(2.02.89) according to what I've found. That's a few releases behind the
2.02.132 I have on my f23 laptop. Nothing in the description creating a
thin-pool requires it's own volume group although sure some "best
practices" indicate creating vg's as the container for a thin-pool.
I can certainly understand and agree in principle to creating a "strong
preference" to have a thin-pool be a libvirt pool because it simplifies
things such as allocated/capacity management and physical device source
listing.
This is my reasoning - with all the thick and thin volumes grouped
together, having free space in one does not mean there is free space for
another.
So should I assume then the desire from the review viewpoint is to
not
support thin lv's at this point in time?
s/time/code/
But I cannot speak for the silent majority.
And that would be because we
want them to be configured a specific way? FWIW: if someone did that -
we still won't be able to support it without this patch.
How so? This patch displays the thin ('V') volumes in type='logical'
pools. With a new pool type, the 'logical' pool could keep ignoring
the thin pools and volumes, just like we skip directories in 'fs' pools.
Any thoughts on the VIR_STORAGE_VOL_LOGICAL*_REGEX's? (depending
on the
answer to the prior question with the obvious change of using S+ instead
of S* for devices)?
They do look more readable to me.
Jan