[dm-devel] Re: [PATCH v2] expose dm-stripe target's topology I/O hints
Mike Snitzer
snitzer at redhat.com
Thu Aug 27 14:24:51 UTC 2009
On Thu, Aug 27 2009 at 10:19am -0400,
Mike Snitzer <snitzer at redhat.com> wrote:
> On Thu, Aug 27 2009 at 9:12am -0400,
> Alasdair G Kergon <agk at 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
More information about the dm-devel
mailing list