On 2/1/2013 11:53 AM, Ewan D. Milne wrote:
> The mechanism used is to flag when certain UA ASC/ASCQ codes are received
> that report asynchronous changes to the storage device configuration. An
> appropriate uevent is then generated for the scsi_device or scsi_target
> object. An aggregation mechanism is used to avoid generating uevents at
> too high a rate, and to coalesce multiple UAs reported by LUNs on the same
> target for a REPORTED LUNS DATA HAS CHANGED sense code.
What happened to this patch? The trail of suggested fixes for the
REPORT LUNS
DATA HAS CHANGED check condition is getting pretty long. The number of devices
(our product included) in the field that have the ability to on the fly modify
the luns on an I_T nexus is not decreasing.
Is it because these patches are trying to fix more than one thing?
What is the preferred way to fix this?
Why not simply add a couple sdev_evt_send_simple()'s and an event
coalesce
function to collapse this event when its received from multiple LUNs on the
I_T? A couple extra uevents isn't going to kill udev right? A really fancy
patch could attempt to clear the check conditions from LUNs that share the I_T.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
