Hi Mike,
My concerns are:
i) The current behaviour is upstream; by changing this aren't you
making the tools writers life more complicated rather than less by
making them support both interfaces?
ii) 16G is a ludicrous amount of space to allocate for metadata (16M
would be much better). Why are the tools trying to allocate this
much? LVM2's unit of _allocation_ may be the extent, but this is
separate from activation. If your extent size is 16G you can
probably squeeze 1000 metadata areas into there.
As a side issue it's not clear to me why anyone would want to use
16G extents? (eg, 16M extents lets them address 2^56 bytes of
data in the VG). Maybe the sys admins mistakenly think they're
getting performance benefits through having more contiguous data?
[LVM2's allocation policies try and allocate contiguous extents
anyway].
If you can reassure me about (i) and that your patch isn't encouraging
poor tool code (ii), then I'll ack this patch.
- Joe
On Fri, Mar 02, 2012 at 04:32:33PM -0500, Mike Snitzer wrote:
> The thin metadata format can only make use of a device that is <=
> METADATA_DEV_MAX_SECTORS (currently 15.9375 GB). Therefore, there is no
> practical benefit to using a larger device.
>
> However, it may be that other factors impose a certain granularity for
> the space that is allocated to a device (E.g. lvm2 can impose a coarse
> granularity through the use of large, >= 1 GB, physical extents).
>
> Rather than reject a larger metadata device, during thin-pool device
> construction, switch to allowing it but issue a warning if a device
> larger than METADATA_DEV_MAX_SECTORS_NEAREST_POWER_OF_2 (16 GB) is
> provided. Any space over 15.9375 GB will not be used.
>
> Signed-off-by: Mike Snitzer <snitzer@xxxxxxxxxx>
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
