On Mon, Mar 05 2012 at 9:04am -0500,
Mike Snitzer <email@example.com> wrote:
> On Mon, Mar 05 2012 at 5:21am -0500,
> Joe Thornber <firstname.lastname@example.org> 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"
dm-devel mailing list