Tejun Heo, on 07/28/2010 06:23 PM 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?
Basically, ACA suspends the whole queue in case if a command in the head
finished with CHECK CONDITION status. The queue should be resumed later
by CLEAR ACA Task Management function. During ACA one or more new
commands can be sent in the head of the queue. It allows, eg, restart
the failed command.
UA_INTLCK allows to establish a Unit Attention if a command in the head
finished with error other that CHECK CONDITION status. Then next command
will finish with CHECK CONDITION and then ACA comes into action.
Overall, they look as a complete facility for effective errors recovery
of ordered queues.
Furthermore, although they do relax ordering
requirements from the device queue side, the level of flexibility is
significantly lower compared to what filesystems can do themselves.
Can you elaborate more what is not sufficiently flexible in SCSI
ordered commands, please?
File systems are not communicating enough ordering info to block layer
already so we already lose a lot of ordering information there and
SCSI ordered queueing is also pretty restricted in what kind of
ordering it can represent.
What restrictions do you mean?
The end result is that we don't gain much
by using ordered queueing. It may cut down command latencies among
commands used for barrier sequence but if you compare it to the level
of parallelism filesystem code can exploit by ordering requests
themselves... Another thing is coverage. We have ordered queueing
for quite some time now but there are only a couple of drivers which
actually support them.
Agree, file systems should provide full ordering info to the block
level. The block level then should do the best to provide the needed
ordering requirements using available hardware facilities.
Thanks,
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
