[dm-devel] [PATCH] dm thin: relax hard limit on the maximum size of a metadata device
thornber at redhat.com
Mon Mar 5 10:21:34 UTC 2012
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
If you can reassure me about (i) and that your patch isn't encouraging
poor tool code (ii), then I'll ack this patch.
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 at redhat.com>
More information about the dm-devel