Q: aborting commands
I've been meaning to ask this for some time now:
What is the consensus on the meaning of an aborted command?
Most notably in the SCSI LLP standards, a successfully aborted command will NOT return status as non-aborted commands would (normally) do.
1. Should successfully aborted commands call scsi_done()? (of course with result=DID_ABORT)
Quoted 1 line
From the point of view of:
Sometimes, a SCSI LLDD can reply with SUCCESS to a command abortion, BUT the scsi_cmnd structure, including the sg lists may NOT be freed right away, that is, until later time when the driver can get around to it to actually yank out/free its own resources, etc. (This is especially true in queuing models when the command has been submitted to another entity (HW/SF) which also operates on a similar queueing model.) Then the SCSI LLDD can notify SCSI core that all its (SCSI core's) memory is free by calling scsi_done() with DID_ABORT set -- the mid layer would know what has happened and will reuse/reissue/etc the command.
I do realize that the above IS a two-edged sword in many respects, I just rambled it just to show another point of view, aside the one taken by SCSI LLP (transports/interconnects).
2. Can/Should/Must SCSI core assume that a _successfully_ aborted command did NOT make it to the medium?
This would be especially useful to UL beasts like journalling FSs, databases, etc.
I think that if the device supports it, when SUCCESS has been returned, this should also mean that the command did NOT make it to the medium. (This would also make it consistent to the semantics of aborting a command.)
Of couse ``medium'' may just mean some cache/buffer on the lowest point of the physical device (or whatever the manuf. decided to muster up), but should nevertheless mean that a READ on the media should give consistent results with aborting the command not making it to the media.
?
Signature · 1 line
Luben
Quoted 8 lines · Luben Tuikov [[email protected]] wrote:
I've been meaning to ask this for some time now:
What is the consensus on the meaning of an aborted command?Most notably in the SCSI LLP standards, a successfully aborted command will NOT return status as non-aborted commands would (normally) do.
1. Should successfully aborted commands call
scsi_done()? (of course with result=DID_ABORT)
The new eh on calling eh_abort_handler on a cmd believes that it is the owner of the command again.
I also noticed an issue in our current error handling in that if call eh_abort_handler we may want to call eh_device_reset_handler on the device later in recovery. The issue is that it at least one implementation by a LLDD this is a either / or case not a progressive step of error recovery.
Quoted 12 lines
Quoted 2 lines
From the point of view of:
Sometimes, a SCSI LLDD can reply with SUCCESS to a command abortion, BUT the
scsi_cmndstructure, including the sg lists may NOT be freed right away, that is, until later time when the driver can get around to it to actually yank out/free its own resources, etc. (This is especially true in queuing models when the command has been submitted to another entity (HW/SF) which also operates on a similar queueing model.) Then the SCSI LLDD can notify SCSI core that all its (SCSI core's) memory is free by callingscsi_done()withDID_ABORTset -- the mid layer would know what has happened and will reuse/reissue/etc the command.
Quoted 7 lines
I do realize that the above IS a two-edged sword in many respects, I just rambled it just to show another point of view, aside the one taken by SCSI LLP (transports/interconnects).
2. Can/Should/Must SCSI core assume that a _successfully_ aborted command did NOT make it to the medium?
How could a LLDD know where the error occurred on a timeout. Take FC for example the problem could be a dropped response IU (with device completing the cmd) or a class 3 data frame dropped in the middle.
Quoted 11 lines
This would be especially useful to UL beasts like journalling FSs, databases, etc.
I think that if the device supports it, when SUCCESS has been returned, this should also mean that the command did NOT make it to the medium. (This would also make it consistent to the semantics of aborting a command.)
Of couse ``medium'' may just mean some cache/buffer on the lowest point of the physical device (or whatever the manuf. decided to muster up), but should nevertheless mean that a READ on the media should give consistent results with aborting the command not making it to the media.
-andmike
--
Michael Anderson
[email protected]
Quoted 5 lines · Mike Anderson
Quoted 3 lines · Luben Tuikov [[email protected]] wrote:
I've been meaning to ask this for some time now:
What is the consensus on the meaning of an aborted command?
Quoted 8 lines
Quoted 5 lines
Most notably in the SCSI LLP standards, a successfully aborted command will NOT return status as non-aborted commands would (normally) do.
1. Should successfully aborted commands call
scsi_done()? (of course with result=DID_ABORT)The new eh on calling
eh_abort_handleron a cmd believes that it is the owner of the command again.
Yes, we know. That's why the ability to sleep on eh, else there's no way out...
Quoted 5 lines
I also noticed an issue in our current error handling in that if call
eh_abort_handlerwe may want to calleh_device_reset_handleron the device later in recovery. The issue is that it at least one implementation by a LLDD this is a either / or case not a progressive step of error recovery.
I don't understand this.
Quoted 3 lines
How could a LLDD know where the error occurred on a timeout. Take FC for example the problem could be a dropped response IU (with device completing the cmd) or a class 3 data frame dropped in the middle.
Right, in this case it cannot.
Anyway I was just throwing ideas and questions to increase the brainstorm pool at linux-scsi, nothing more.
Signature · 1 line
Luben
Quoted 9 lines · Luben Tuikov [[email protected]] wrote:
Quoted 8 lines · Mike Anderson
Quoted 6 lines · Luben Tuikov [[email protected]] wrote:
I've been meaning to ask this for some time now:
What is the consensus on the meaning of an aborted command?Most notably in the SCSI LLP standards, a successfully aborted command will NOT return status as non-aborted commands would (normally) do.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
1. Should successfully aborted commands call
scsi_done()? (of course with result=DID_ABORT)The new eh on calling
eh_abort_handleron a cmd believes that it is the owner of the command again.Yes, we know. That's why the ability to sleep on eh, else there's no way out...
Ok so is the question should "all" io complete through scsi_done?
When I looked at faster recovery of a timed out commands I was trying to determine if it would be simpler for the abort io to call scsi_done. I thought it would be because ownership would be cleaner.
It would also be good to start the abort ASAP on a timeout but the context is wrong if the LLDD needs to sleep.
-andmike
--
Michael Anderson
[email protected]