On 02/04/2016 04:53 AM, Ján Tomko wrote:
On Wed, Feb 03, 2016 at 03:51:30PM -0500, John Ferlan wrote:
On 02/03/2016 03:23 AM, Ján Tomko wrote:
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:
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'.
We could if our logic to create/build the pool was overhauled or perhaps support was added to have two volume groups use the same source device.
Since it's possible to place a thin_pool in the same vg as a snapshot and a "thick" lv, should we be in the business of splitting hairs and trying to define how things should be viewed?
We already are. E.g. in the 'fs' pool, we ignore fifos and subdirectories.
True we don't follow any subdir for an 'fs' pool (or 'dir' pool); however, a 'thin-pool' and 'thin' lv are both in a VG. The hierarchy is managed by LVM. If you looked at the on disk structure you'd only find the 'thin' subdir, but there is no 'thin-pool' subdir.
I don't see the benefit behind requiring the user to decide whether to have a libvirt pool view either thin lv's or non-thin lv's of their vg or requiring their vg to essentially be one thin-pool in order to support thin lv's, when we could support whatever configuration they've already developed.
The thin pool would view the thin volumes in a specific thin pool, not all thin pools in that VG.
Sure I understand the goal - a 1-to-1 relationship between a thin-pool in a volume group and the libvirt pool. Then a 1-to-n relationship between the pool and it's thin lv's. If a VG had two thin-pools, then each would have to be it's own libvirt pool. Configuring the libvirt specific pool is an extra step or two. The libvirt pool would list the thin-pool size as capacity and the allocation could be based on the data_percent. Perhaps the one benefit I can see from this model. I do see a lot of extra code, documentation, and configuration steps.
If more work is done in LV pools - are we going to create new pool types for other lvm segtypes ("mirror", "stripe", "raid", etc.)? In order to display/fetch interesting or specific things about them?
AFAIK none of these create another pool on top of the VG.
True - not in the same manner as a thin-pool and thin lv have an overt relationship. However, thin lv's and thin-pool's are listed within a VG not on top of a VG. The thin-pool is just the mechanism used to define the physical storage extents from which the virtual 'thin' extents can be drawn from. If the thin-pool runs out of extents, the admin must come along and extend it. That is - libvirt is not involved. No different than if a VG (without a thin-pool) ran out of space. The admin would need to extend it via some LVM command. Again libvirt is hands off. I see creating a separate pool as a needless hierarchical step for the primary benefit of being able to display the capacity of the thin-pool. I think it's easier to describe that a logical pool that contains thin lv's can appear to be over-subscribed. Management of the thin-pool's from which those thin lv's draw from is left to LVM similar to whatever configuration steps are required to create a device path for an 'fs' pool to use. John