Jeff Garzik wrote:
James Bottomley wrote:
I suppose I'm a broken record, but I really think linked tasks are the
better way to enforce the required ordering guarantees for SCSI TCQ.
The problem being that this would present a slightly different API at
the block level (you have individual writes that are now ordered, not
wholesale barriers).
I strongly agree, since fundamentally, linked tasks is what is really
going on.
Hello, James. Hello, Jeff.
Maybe I have misunderstood, but, AFAICS, linked task doesn't assure any
ordering relation with respect to other tasks unlike ordered tag. So,
it doesn't make much difference compared to simple & stupid ordering by
draining. For a barrier to work, the following order should be kept.
pre-barrier writes -> cache flush -> barrier write (FUA) -> other writes
Issuing cache flush and barrier write with ordered tags accomplishes all
the ordering requirements (if it works, that is.). I can see linked
task can be used for 'cache flush -> barrier write (FUA)' segment but
that leaves us with two unhandled ordering requirements.
Another thing I'm curious about linked task is what advantages linked
task has over simply issuing and completing the commands sequentially.
Commands in a linked task has to be issued and completed sequentially
anyway, so I don't really see the difference.
Thanks.
--
tejun
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
