On Mon, Mar 05 2012 at 5:21am -0500, Joe Thornber <thornber@xxxxxxxxxx> 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
