Re: dm thin: relax hard limit on the maximum size of a metadata device

[Mike Snitzer <snitzer@redhat.com>]

On Mon, Mar 05 2012 at  9:04am -0500,
Mike Snitzer <snitzer@redhat.com> wrote:

> On Mon, Mar 05 2012 at  5:21am -0500,
> Joe Thornber <thornber@redhat.com> wrote:
> 
> > 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?
> 
> It is an incremental improvement.  Allows the kernel to be forgiving.
> How does this impact some tool that took the special care to limit the
> size of the device to METADATA_DEV_MAX_SECTORS (which is < 16G)?
> 
> I'm not imposing new or conflicting restrictions that would trip up any
> existing/hypothetical tools.
> 
> > 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].
> 
> Whatever the tools may be doing is not my concern.  Ideally the users
> and tool authors understand that 16G is insane for thinp metadata.  But
> in the event that they use 16G would you rather we reject them?
> I do think so, especially given that we've already documented that 16G
> is the max.

I clearly meant "I do _not_ think so" ;)