Re: [PATCH] queue barrier support

[Chris Mason <mason@suse.com>]

On Friday, February 15, 2002 10:15:58 AM -0500 James Bottomley <James.Bottomley@steeleye.com> wrote:

> mason@suse.com said:
>> I was wondering about this, we would need to change the error handler
>> to  fail all the requests after the barrier.  I was hoping the driver
>> did this for us ;-) 
> 
> Unfortunately, this is going to involve deep hackery inside the error handler. 
>  The current initial premise is that it can simply retry the failing command 
> by issuing an ABORT to the tag and resending it (which can cause a tag to move 
> past your barrier).  In an error situation, it really wouldn't be wise to try 
> to abort lots of potentially running tags to preserve the barrier ordering 
> (because of the overload placed on a known failing component), so I think the 
> error handler has to abandon the concept of aborting commands and move 
> straight to device reset.  We then carefully resend the commands in FIFO order.
> 

Ok, I'll try to narrow the barrier usage a bit, I'm waiting on the
barrier write once it is sent, so I'm not worried about anything done
after the ordered tag.

write X log blocks   (simple tag)
write 1 commit block (ordered tag)
wait on all of them.

All I care about is knowing that all of the log blocks hit the disk
before the commit.  So, if one of the log blocks aborts, I want it
to abort the commit too.  Is this a little easier to implement?

> Additionally, you must handle the case that a device is reset by something 
> else (in error handler terms, the cc_ua [check condition/unit attention]).  
> Here also, the tags would have to be sent back down in FIFO order as soon as 
> the condition is detected.
> 
> mason@suse.com said:
>> Yes, this could get sticky.  Does anyone know if other OSes have
>> already done this? 
> 
> Other OSs (well the ones I've heard about: Solaris and HP-UX) try to avoid 
> ordered tags, mainly because of the performance impact they have---the drive 
> tag service algorithms become inefficient in the presence of ordered tags 
> since they're usually optimised for all simple tags.

I do see that on my drives ;-)  The main reason I think its worth trying
is because the commit block is directly adjacent to the last log block,
so I'm hoping the drive can optimize the commit (even though it is ordered)
better when the OS sends it directly after the last log block.

While I've got linux-scsi cc'd, I'll reask a question from yesterday.
Do the targets with write back caches usually ignore the order tag, 
doing the write in the most efficient way possible instead?

-chris