On Mon, 2013-07-22 at 15:31 +0000, James Bottomley wrote: > Ping on this, please. > > I have another possible consumer of this infrastructure, when it's > ready, which is the SCSI RAID drivers. We've been getting complaints > that there's no event we get from them when a RAID system goes from > online -> degraded which should be the sysadmin's cue to go in and > replace the disk (well, this isn't quite true, a lot come with > proprietary monitoring daemons which do this, but they're pretty unique > per controller). > > I was thinking we might resurrect the orphaned raid_class.c to do this > and give a universally displayable but rudimentary view of the topology > and health of the device and add an easy hook for RAID events. > > James > I'm testing a v4 version of these patches, which address your earlier comments. I'm still working on the code to suppress the duplicate REPORTED LUNS DATA HAS CHANGED unit attentions from multiple LUNs. As I mentioned in my earlier mail, doing this with the expected_cc_ua mechanism is imperfect, because SCSI-3 devices will stop reporting it when one of the LUNs on the target *receives* a REPORT LUNs command, and it is difficult to know when this happens. I'm trying out clearing the flag before the SCSI scan code issues a REPORT LUNs, that might be good enough. (It doesn't handle someone from sending this command through the sg driver, though.) Will post the v4 soon. -Ewan -- 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
