Re: [RFC] relaxed barrier semantics

[Vladislav Bolkhovitin <vst@vlnb.net>]

James Bottomley, on 07/28/2010 06:37 PM wrote:
> On Wed, 2010-07-28 at 16:23 +0200, Tejun Heo wrote:
>> Hello,
>>
>> On 07/28/2010 03:55 PM, Vladislav Bolkhovitin wrote:
>>>> The only benefit of doing it in the block layer, and probably the
>>>> reason why it was done this way at all, is making use of advanced
>>>> ordering features of some devices - ordered tag and linked commands.
>>>> The latter is deprecated and the former is fundamentally broken in
>>>> error handling anyway.
>>>
>>> Why? SCSI provides ACA and UA_INTLCK which provide all needed
>>> facilities for errors handling in deep ordered queues.
>>
>> I don't remember all the details now but IIRC what was necessary was
>> earlier write failure failing all commands scheduled as ordered.  Does
>> ACA / UA_INTLCK or whatever allow that?
>
> No.  That requires support for QErr ... which is in the same mode page.
>
> The real reason we have difficulty is that BUSY/QUEUE_FULL can cause
> reordering in the issue queue, which is a driver problem and not in the
> SCSI standards.

BTW, I for long time wandering why low level drivers should process 
BUSY/QUEUE_FULL and perform adjusting the queue depth. Isn't it common 
for the drivers, so should be performed on the higher (SCSI) level? This 
level would provide facility to prevent reordering, if needed, and the 
driver would communicate with it in a transparent level.

I mean the following. A driver always deals with a single command at 
time. It either sends the command to the device, or sends command's 
status/sense from the device to the SCSI level. Then SCSI level decides 
if to send another command to the driver or perform necessary recovery, 
eg, adjusting queue depth or using ACA restarting the QUEUE_FULL'ed command.

In this architecture there would not be needed to update all the drivers 
to provide ordering guarantees and ACA based recovery as it seems needed 
now.

Or, am I missing something?

Thanks,
Vlad