Re: [PATCH] ide write barrier support

[Nick Piggin]

Daniel Phillips wrote:

> On Thursday 23 October 2003 18:23, Jens Axboe wrote:
>
> > On Thu, Oct 23 2003, Daniel Phillips wrote:
> >
> > > I'm specifically interested in working out the issues related to stacked
> > > virtual devices, and there are many.  Let me start with an easy one.
> > >
> > > Consider a multipath virtual device that is doing load balancing and
> > > wants to handle write barriers efficiently, not just allow the
> > > downstream queues to drain before allowing new writes.  This device
> > > wants to send a write barrier to each of the downstream devices,
> > > however, we have only one write request to carry the barrier bit.  How
> > > do you recommend handling this situation?
> > That needs something to hold the state in, and a bio per device. As
> > they complete, mark them as such. When they all have completed, barrier
> > is done.
> >
> > That's just an idea, I'm sure there are other ways. Depending on how
> > complex it gets, it might not be a bad idea to just let the queues drain
> > though. I think I'd prefer that approach.
>
> These are essentially the same, they both rely on draining the downstream 
> queues.  But if we could keep the downstream queues full, bus transfers for 
> post-barrier writes will overlap the media transfers for pre-barrier writes, 
> which would seem to be worth some extra effort.
>
> To keep the downstream queues full, we must submit write barriers to all the 
> downstream devices and not wait for completion.  That is, as soon as a 
> barrier is issued to a given downstream device we can start passing through 
> post-barrier writes to it.
>
> Assuming this is worth doing, how do we issue N barriers to the downstream 
> devices when we have only one incoming barrier write?

You would do this in the multipath code, wouldn't you?

Anyway, I might be missing something, but I don't think draining the
queue will guarantee that writeback caches will go to permanent storage.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/