FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 03-05-2012, 09:21 AM
Joe Thornber
 
Default dm thin: relax hard limit on the maximum size of a metadata device

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@redhat.com>

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-05-2012, 01:04 PM
Mike Snitzer
 
Default dm thin: relax hard limit on the maximum size of a metadata device

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.

> If you can reassure me about (i) and that your patch isn't encouraging
> poor tool code (ii), then I'll ack this patch.

OK... let me know if I passed

Mike

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-05-2012, 01:19 PM
Mike Snitzer
 
Default dm thin: relax hard limit on the maximum size of a metadata device

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"

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-06-2012, 09:09 AM
Joe Thornber
 
Default dm thin: relax hard limit on the maximum size of a metadata device

On Mon, Mar 05, 2012 at 09:04:21AM -0500, Mike Snitzer 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)?

You're making this change to make life easier for tool writers, yet
tool writers still have to support the existing 3.2 kernel and deal
with the 16G limit.

> 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?

Yes, I would rather reject, than let people think they had 32G of
metadata. It also forces the tool writers to do something sane.

I don't feel strongly enough about this to keep arguing. So consider
this an ACK and see if you can get it past Alasdair.

- Joe

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 09:36 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org