scsi logging
Quoted 4 lines · Andrew
I'd like to propose the following patch to 3 SCSI mid-layer files from kernel 2.4.3. I have tested this with 2.4.3, but it should be relevant to other 2.4.x kernels also.
Quoted 14 lines
It has the following changes/enhancements:
1) Log the disk serial number duringscsi_scan()
-scsi_scan.c.
Why: This is a requirement in some environments to ensure unambiguous identification of a particular problem disk.
2) Interpret additional values inprint_sense_internal()
-constants.c. Why: The detail wrt Illegal Requests is very useful, since it can indicate either an application bug or an incompatible feature of the device.
3) Don't skip logging sense errors for sg functions -sg.c.
Why: All sense errors should be logged so that a potential scsi device hardware problem doesn't go unrecognized.
Andrew,
I would object to point 3). SANE, and to a lesser extent cdrecord, execute lots of commands that give SCSI check conditions and would bloat the log and the console with many serious looking messages. Those error indications are conveyed back to the app via the sg interface so the information is not lost. There is an ioctl in the sg driver [SG_SET_DEBUG] to turn on that output to the log/console [the default is off (to stop the curious querying the maintainer about the strange messages in their logs)].
Doug Gilbert
Hi Andy, a name from the past... :-)
I agree with Doug. I think the behavior of the sg driver to not log errors or do retries is appropriate. To put in context to yours and mine past lives, NCR MP/RAS had similar functionality in the libscsi interface. That interface also turned error logging and retries off by default. This is necessary for an interface that is to be used for error diagnosis, recovery, probing and the like.
LifeKeeper uses the sg driver to probe for devices and to get the serial number that you listed in (1) in the original request. This can and will generate errors that one would not want logged. The difficult part about logging errors is the "thundering herd" problem. If you log a lot of unnecessary or meaningless errors then the "real" errors are lost in the flow.
I think one of the responsibilities of using the sg driver is that an
application has to handle the errors that will occur and log or retry as appropriate.
I think SANE and cdrecored are just two examples of programs that expect this behavior (no logging of errors). LifeKeeper is another example. I would be willing to bet there are others. So changing this behavior could have a wide ranging affect.
Getting back to your first comment (sorry I have already deleted your initial mail) did you provide the patch for getting the serial number? Note that getting the serial number is not a required SCSI feature so you wont get 100% of the devices.
Eddie Williams
Quoted 36 lines
Quoted 4 lines · Andrew
I'd like to propose the following patch to 3 SCSI mid-layer files from kernel 2.4.3. I have tested this with 2.4.3, but it should be relevant to other 2.4.x kernels also.
Quoted 14 lines
It has the following changes/enhancements:
1) Log the disk serial number duringscsi_scan()
-scsi_scan.c.
Why: This is a requirement in some environments to ensure unambiguous identification of a particular problem disk.
2) Interpret additional values inprint_sense_internal()
-constants.c. Why: The detail wrt Illegal Requests is very useful, since it can indicate either an application bug or an incompatible feature of the device.
3) Don't skip logging sense errors for sg functions -sg.c.
Why: All sense errors should be logged so that a potential scsi device hardware problem doesn't go unrecognized.Andrew,
I would object to point 3). SANE, and to a lesser extent cdrecord, execute lots of commands that give SCSI check conditions and would bloat the log and the console with many serious looking messages. Those error indications are conveyed back to the app via the sg interface so the information is not lost. There is an ioctl in the sg driver [SG_SET_DEBUG] to turn on that output to the log/console [the default is off (to stop the curious querying the maintainer about the strange messages in their logs)].Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
While I would like to see scsi scan pick up / print serial numbers or a form of device UUID I have to agree with Eddie that this patch would only provide data for devices that decided to fill in the vendor specific area of the standard inquiry page.
A more generic solution would involve two more inquiry commands to the device using the EVPD bit. The first would be to request page 0 and then working from highest to lowest use page 0x83, 0x80, stanard inquiry page (vendor, product, serial). In some cases though with really old devices this still might not generate useful information.
-Mike
Quoted 52 lines · Eddie Williams [[email protected]] wrote:
.. Snip ...
Getting back to your first comment (sorry I have already deleted your initial mail) did you provide the patch for getting the serial number? Note that getting the serial number is not a required SCSI feature so you wont get 100% of the devices.Eddie Williams
Quoted 32 lines
Quoted 4 lines · Andrew
I'd like to propose the following patch to 3 SCSI mid-layer files from kernel 2.4.3. I have tested this with 2.4.3, but it should be relevant to other 2.4.x kernels also.
Quoted 14 lines
It has the following changes/enhancements:
1) Log the disk serial number duringscsi_scan()
-scsi_scan.c.
Why: This is a requirement in some environments to ensure unambiguous identification of a particular problem disk.
2) Interpret additional values inprint_sense_internal()
-constants.c. Why: The detail wrt Illegal Requests is very useful, since it can indicate either an application bug or an incompatible feature of the device.
3) Don't skip logging sense errors for sg functions -sg.c.
Why: All sense errors should be logged so that a potential scsi device hardware problem doesn't go unrecognized.Andrew,
I would object to point 3). SANE, and to a lesser extent cdrecord, execute lots of commands that give SCSI check conditions and would bloat the log and the console with many serious looking messages. Those error indications are conveyed back to the app via the sg interface so the information is not lost. There is an ioctl in the sg driver [SG_SET_DEBUG] to turn on that output to the log/console [the default is off (to stop the curious querying the maintainer about the strange messages in their logs)].Quoted 4 lines
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 2 lines
Michael Anderson [email protected]