James Bottomley wrote:
And please close this as invalid. FS ordering guarantees in linux
aren't done via ordered tags.
I had a related question. I was working on the attached patch for soe
other testing (patch made against scsi-rc-fixes, but is not stable so do
not apply), which does the scsi_populate_tag_msg conversion from MSG_*
to ISCSI_ATTR and sets the proper iscsi bits.
If I do this patch where I call scsi_activate_tcq on a device and that
concertsion, does this require that my driver not reorder commands? I
was just a little worried on some of the error handling paths where we
requeue commands to the mid layer.
Right, there's no way of guaranteeing that commands aren't reordered in
the error path (or even the queue full submission path) which is why we
don't use ordered tags to enforce barriers.
May I make your answer more precise? SCSI for non-caching and
write-through caching devices provides a way to guarantee order of
commands on the error path via ACA and UA_INTLCK facilities, if they are
supported by device. For write-back caching devices it's different,
because cache may reorder commands after they are reported as completed
to the initiator as well as there is a possibility for deferred errors.
So, there is no way to guarantee commands order in case of errors,
because Linux doesn't implement that.
BTW, there is still something wrong in the SCSI/block/FS layers error
processing. Playing with my SCSI target I've noticed that if it returns
pretty valid TASK ABORTED status for some SCSI command, FS on initiator
(ext3) immediately gets corrupted and journal replay on remount doesn't
repair it, only manual e2fsck helps. So, apparently:
1. SCSI ML handles well not all status codes, which it should.
2. Block/FS levels (sometimes) don't handle I/O errors well enough
without corrupting file systems.
I don't have time for further investigations, but, if somebody prepare a
patch to fix that, I'm willing to assist in testing.
Vlad
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
