Re: [PATCH v2] dm: add topology support

[Mike Snitzer <snitzer@redhat.com>]

On Wed, Jun 10 2009 at  1:58pm -0400,
Martin K. Petersen <martin.petersen@oracle.com> wrote:

> >>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:
> 
> Mike> So the question: is _not_ using the blk_queue_*() setters
> Mike> perfectly fine?  Given that DM has always _not_ used them the
> Mike> quick answer is "seems fine".
> 
> Mike> But I need to dig a bit more to understand if the additional logic
> Mike> in the blk_queue_*() setters is something DM shouldn't be
> Mike> circumventing.
> 
> The original intent was that drivers like DM and MD would seed their
> limits using the blk_queue* calls before adding any component devices.
> blk_stack_limits() would then scale accordingly for every new device
> added.
> 
> Is there any reason in particular that this approach wouldn't work for
> DM?  I.e. set defaults ahead of time instead of doing it upon table
> completion using check_for_valid_limits()?

When a table is pushed to DM each target device in the table may have
different limits.  There is no one-size-fits-all default.

With DM, the underlying device that you're sending IO to is a function
of offset into the DM device.  Therefore, the associated IO limits
should really be a function of offset.

Understanding that that is a more complicated proposition we're working
with the topology infrastructure that you've put together as best we
can.

That means we use a device's alignment_offset in userland LVM2 to push
down a data area whose start+size is aligned.  This gives us the
guarantee that each device in a given DM table is aligned.  From there
DM will use blk_stack_limits() to combine all the other topology limits
(alignment_offset is no longer an issue; though we could get some
warnings.. may look to silence them in dm-table.c).

But blk_stack_limits() leads to a situation where the combined limits
(io_min, logical_block_size) are not ideal for all offsets into the
resulting DM device (e.g. issuing larger IOs to some target devices than
would otherwise be needed).

This is not new for DM (historically DM stacked hardsect_size and other
limits in the same fashion), but it doesn't mean that we aren't keeping
in mind that limits as a function of offset would be more appropriate.

Mike