Re: [PATCH] ide write barrier support

[Daniel Phillips]

On Friday 24 October 2003 01:21, Nick Piggin wrote:
> Daniel Phillips wrote:
> > 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?

Not entirely within the multipath virtual device, that's the problem.  If it 
could stay somehow all within one device driver then ok, but since we want to 
build this modularly, as a device mapper target, there are API issues.

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

We moved on from the IDE writeback problem a while back, this is about SCSI 
multipath, and the idea is to keep the SCSI device queues full so that 
barrier requests can flow through instead of stalling.

To be honest, after poring through the SCSI docs I'm not sure whether SCSI 
supports the behavior I want, which is for dma transfers on post-barrier 
requests to run in parallel with media transfers of pre-barrier requests.

With SCSI there are two mechanisms that could be used to implement barriers, 
ordered commands and task lists; patches posted to date use the first method.  
The ordered method sets an attribute on a SCSI write command that says "must 
be executed in order submitted" implying that all previously submitted 
commands have to finish before the ordered command begins to execute.  (Note, 
this is not necessarily optimal if the barrier is just supposed to separate 
two groups of writes and the order within the second group doesn't matter.  
Also, it implements a stronger barrier than just read/write, so reads will be 
blocked as well.)  What is not clear to me is whether or not the drive is 
allowed to read the buffer into its cache before the ordered command becomes 
active.  I'd appreciate comments from any SCSI gurus that happen to be 
reading.

Regards,

Daniel

-
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/