Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 24 Oct 2003 09:21:26 +1000 | From | Nick Piggin <> | Subject | Re: [PATCH] ide write barrier support |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |