Integrated Unit Attention handling
Hi all,
I'd like to discusss 'Integrated Unit Attention handling' at LSF/MM 2015.
Currently we're interpreting some Unit Attention codes and send out uevents, with the hope that some userspace application will make use of this.
However, some UAs are easily handled within the kernel directly, eg
- REPORT LUN DATA CHANGED: this could easily trigger a rescan of the scsi host driving that LUN.
- INQUIRY DATA CHANGED: Rescan the VPD pages and INQUIRY data itself
When implementing such an integrated UA handling, however, we would need to revisit the design choice of having the inquiry data fixed to struct scsi_device. Currently any modification to the inquiry data requires a complete device removal; this is not really feasible for integrated event handling.
I'd like to discuss if such an integrated UA handling is desirable and, if so, if devices should become flexible to have the inquiry data changed on the fly.
Cheers,
Hannes
Signature · 9 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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
Sounds like a good topic, altough I hope we'll see considerable progress before LSF on this item..
Quoted 3 lines · Christoph Hellwig
Sounds like a good topic, altough I hope we'll see considerable progress before LSF on this item..
Full integration requires a change of the SCSI device model; currently struct scsi_device has a fixed type and inquiry data, so rescan is essentially a no-op.
So the current model requires the complete removal of the device and a rescan on the host.
Doing that from within the SCSI stack will open quite some interesting race conditions, let alone interesting userspace interactions.
Alternatively we can change the model to allow for a change of the inquiry data, but that should be discussed.
And then there is the Power-On/Reset handling, which probably would warrant a discussion on its own ...
Cheers,
Hannes
Signature · 9 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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
Quoted 4 lines · Hannes Reinecke
Quoted 3 lines · Christoph Hellwig
Sounds like a good topic, altough I hope we'll see considerable progress before LSF on this item..
Quoted 10 lines
Full integration requires a change of the SCSI device model; currently struct
scsi_devicehas a fixed type and inquiry data, so rescan is essentially a no-op.
So the current model requires the complete removal of the device and a rescan on the host.
Doing that from within the SCSI stack will open quite some interesting race conditions, let alone interesting userspace interactions.
Alternatively we can change the model to allow for a change of the inquiry data, but that should be discussed.
For now we can just react to new LUNs or size changes, which would be what most people want, and offline devices for anything else.
That alone would be a gigantic improvement.
Quoted 15 lines · Hannes Reinecke
Quoted 2 lines · Christoph Hellwig
Sounds like a good topic, altough I hope we'll see considerable progress before LSF on this item..
Full integration requires a change of the SCSI device model; currently struct
scsi_devicehas a fixed type and inquiry data, so rescan is essentially a no-op.
So the current model requires the complete removal of the device and a rescan on the host.
Doing that from within the SCSI stack will open quite some interesting race conditions, let alone interesting userspace interactions.
Alternatively we can change the model to allow for a change of the inquiry data, but that should be discussed.
Quoted 2 lines
And then there is the Power-On/Reset handling, which probably would warrant a discussion on its own ...
Hello Hannes and Christoph,
If any of the topics raised by Hannes have not been resolved before the LSF/MM starts I'm definitely interested in attending this discussion.
Bart.