On Mon, Mar 05 2012 at 9:04am -0500, Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > 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. I clearly meant "I do _not_ think so" ;) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
