I like that concept. Since TMFs are protocol specific, though, it is possible that the SCSI initiator port doesn't know how to send a TMF even though the device server supports that TMF. The SCSI Architecture Model (SAM-5) standard includes an annex listing a variety of SCSI Initiator Port attributes and SCSI Target Port attributes that can limit what an application client and device server can do: - LUN size - Maximum CDB length - Command Identifier size (i.e. tag size) - Task Attributes supported (which ones) (e.g., SIMPLE, HEAD OF QUEUE, ORDERED, ACA) - Maximum Data-In Buffer size - Maximum Data-Out Buffer size - Command Reference Number supported? - Command Priority supported? - Maximum Sense Data length - Status Qualifier supported? - Additional Response Information supported? - Bidirectional Commands supported? - TMFs supported (which ones) How the application client determines what the SCSI initiator port supports is outside the scope of the SCSI standards - there's no SCSI command or TMF to report that information. These attributes are first constrained by the SCSI transport protocol (e.g., SRP doesn't define an encoding for QUERY TASK), then by implementation choices (e.g., bidirectional commands and >16-byte CDBs are still not widely supported). Ideally the device driver for the SCSI initiator port would report those attributes, and higher level code would combine them with support information from the device server (REPORT SUPPORTED TMF command, REPORT SUPPORTED OPCODES command, etc.) to decide what is supported. --- Rob Elliott HP Server Storage > -----Original Message----- > From: linux-scsi-owner@xxxxxxxxxxxxxxx [mailto:linux-scsi- > owner@xxxxxxxxxxxxxxx] On Behalf Of Jeremy Linton > Sent: Tuesday, 12 February, 2013 12:20 PM > To: Linux Scsi > Subject: [PATCH] Use a more selective error recovery strategy based on device > capabilities > > Ideally, Linux should not be sending task management commands to devices > that > don't support the given task mgmt operation. > > This patch uses the REPORT SUPPORTED TASK MGMT FUNCTIONS command to > enable or > disable error recovery paths for a given device. For older devices, we make an > educated guess about what kind of error recovery the device supports. This isn't > going to be 100% accurate as it should probably take the transport as well as > the SCSI version into account, but it is a start. > > While this patch improves the error recovery paths for modern SCSI networks, > the > error recovery logic continues to fall through to host reset. It also continues > to send bus and target resets in cases where they may affect working devices. I > have a partial set of patches which attempt to make intelligent decisions in > these cases, but they are far more intrusive and at this point not as clear cut. > > > Just in case... > Signed-off-by: Jeremy Linton <jlinton@xxxxxxxxxxxxx> > --- -- To unsubscribe from this list: 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
