On Wed, 2013-06-19 at 13:42 -0400, Ewan D. Milne wrote:
> From: "Ewan D. Milne" <[email protected]>
>
> Generate a uevent on the scsi_target object when the following
> Unit Attention ASC/ASCQ code is received:
>
> 3F/0E REPORTED LUNS DATA HAS CHANGED
>
> Generate a uevent on the scsi_device object when the following
> Unit Attention ASC/ASCQ codes are received:
>
> 2A/01 MODE PARAMETERS CHANGED
> 2A/09 CAPACITY DATA HAS CHANGED
> 38/07 THIN PROVISIONING SOFT THRESHOLD REACHED
>
> All uevent generation is aggregated and rate-limited so that any
> individual event is delivered no more than once every 2 seconds.
Why? What causes you to think these events would be repeated on a
massive scale. Mode and Capacity changes are signalled only once per
actual change, which doesn't occur very often. SBC-3 says that the TP
thresholds are only signalled once but may be signalled again after a
reset. In general, T10 treats UA as exceptional conditions ... there's
no reason to think they keep repeating.
Dumping all the hand rolled rate limit code would simplify the patch
quite a lot.
> Log kernel messages when the following Unit Attention ASC/ASCQ
> codes are received:
>
> 2A/xx PARAMETERS CHANGED
> 3F/03 INQUIRY DATA HAS CHANGED
> 3F/xx TARGET OPERATING CONDITIONS HAVE CHANGED
>
> Also changed the kernel log messages on existing Unit Attention
> codes, to remove text that indicates that the conditions were not
> handled in any way (since they are now handled in some way) and
> reflect the wording used in SPC-4.
This isn't a good idea because
1. They might not be acted on if there's no actual listener for the
uevent
2. Anyone currently using a log message reaper to process the event
(which is currently the only way of doing it) would now miss it
because the log message has changed.
> Also log a kernel message when the a scsi device reports a Unit
> Attention queue overflow, indicating that status has been lost.
>
> These changes are only enabled when the kernel config option
> CONFIG_SCSI_ENHANCED_UA is set. Otherwise, the behavior is the
> same as before, including the existing kernel log messages.
> However, the detection of these conditions was moved to be earlier
> in scsi_check_sense(), because the code was not always reached.
>
> Added a new exported function scsi_report_sense() to allow drivers
> to report sense data that is not associated with a SCSI command.
No: we don't add APIs until there are consumers. The refactor into
scsi_report_sense is fine, just don't add the export or prototype until
someone comes along with a use case.
James
--
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
