Re: [PATCH v2] expose dm-stripe target's topology I/O hints

[Mike Snitzer <snitzer@redhat.com>]

On Thu, Aug 27 2009 at 10:19am -0400,
Mike Snitzer <snitzer@redhat.com> wrote:

> On Thu, Aug 27 2009 at  9:12am -0400,
> Alasdair G Kergon <agk@redhat.com> wrote:
> 
> > On Fri, Aug 21, 2009 at 10:17:18AM -0400, Mike Snitzer wrote:
> > > Add .io_hints to 'struct target_type' to allow the I/O hints portion of
> > > the 'struct queue_limits' to be set by each target.  Expose dm-stripe
> > > target's topology I/O hints.
> >  
> > Do you still think this should go into 2.6.31?
> 
> Yes, it is important.  Otherwise DM won't expose the proper I/O hints in
> /sys for a striped device.  This is bad because then higher-level tools
> won't be able to rely on that information to properly align ther data
> (e.g. mkfs.extX -E).
> 
> > If so, please supply a revised patch header that explains the benefits
> > of having the patch (and reference the new stuff in 2.6.31 that it
> > uses).
> > 
> > > +	limits->io_opt = chunk_size * sc->stripes;
> > 
> > blk_queue_io_opt() ?

Did you mean why not use blk_limits_io_opt()?
 
> Martin didn't expose such an interface because all existing code (both
> DM and MD) does not require anything beyond a simple assignment.  I
> worked with Martin to establish the blk_queue_io_min() precisely because
> DM needed to avoid duplicating the block layer's logic.  I think Martin
> stopped short of adding a symmetric wrapper for setting io_opt because
> he felt it was unnecessary.  But I could be mis-remembering.

To clarify further; I meant to say blk_limits_io_min() in my above
paragraph.  We don't have access to the queue (because target's don't
have a queue); we're working with 'struct queue_limits *limits'

Mike