Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
Thanks to everyone for the comments on this patch series. Based upon the feedback, I'll be making the following changes to the patch series before submitting it: - Remove patch 1/9 Detect overflow of sense data buffer - Change name of sdev_evt_thread to sdev_evt_work - Change name of starget_evt_thread to starget_evt_work - Pull code out of scsi_check_sense() that handles UAs into an exported function so that drivers can report conditions received asynchronously The discussions about further changes (e.g. AEN, W-LUN) to ensure conditions are reported to the host in the case of no active I/O in progress or no LUNs currently presented have been good. I think this could be addressed with subsequent patches. -Ewan -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/24/2013 8:38 AM, Bart Van Assche wrote: Let me ask this another way. SAN users expect that the LUN list at the initiator side gets updated automatically after a SAN configuration change. How should a SAN system communicate to a SCSI initiator that the LUN list has been changed ? Some FC SAN systems send a LIP after a configuration change to force the initiator to rescan LUNs. But how to What I think your looking for is RSCN (Registered State Change notification) . Hook that, and then check the name server. This will tell you when ports get added/removed. You can then report luns against lun 0 of all the known target ports. This allows you to transparently detect changes. Otherwise, you run the risk of trapping UA's in the lower level portions of the stack that _REALLY_ need to be propagated to the controlling driver or application. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRBpOeAAoJEL5i86xrzcy765gH/AnG1TPJ5Y3RGx00TiLP5shb +yS384FoIis4XuWijUdofsAcnZzUFaMgH7lPBr5TkT1yYDgyXtzvpjV/2rvWlvzA PfHPU4vPFmpF1XO7IX2PJCpHAYheHXhucnMkXVLI9GA5nR9+BPQjjvav24ixGKPc b2889zju7Z7KUb0R4SXWtSCbRZZtYuBj0Rckh8a/ra9wJXHuMpsg7+7OzrLqbSqH OcAmcb5Q8T/5D6Rj4rJVF3d1Fzr5+P2qrMhS+eb98I6phZ5UvHs66nY/pHjCGpbA SShQlGOg7+nIjxsf9jjl2/sgx0jJH40koyW8Xv9WERE75eQ9bVBpBX3BeosvlJs= =isBF -END PGP SIGNATURE- -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On 01/28/13 16:05, Jeremy Linton wrote: What I think your looking for is RSCN (Registered State Change notification). Hook that, and then check the name server. This will tell you when ports get added/removed. You can then report luns against lun 0 of all the known target ports. This allows you to transparently detect changes. Otherwise, you run the risk of trapping UA's in the lower level portions of the stack that _REALLY_ need to be propagated to the controlling driver or application. Thanks for the feedback. Unfortunately sending an RSCN is only possible when using Fibre Channel as transport layer. I'm looking for a solution that also works with other SCSI transports, e.g. iSCSI and SRP. Bart. -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On 01/28/2013 04:44 PM, Bart Van Assche wrote: On 01/28/13 16:05, Jeremy Linton wrote: What I think your looking for is RSCN (Registered State Change notification). Hook that, and then check the name server. This will tell you when ports get added/removed. You can then report luns against lun 0 of all the known target ports. This allows you to transparently detect changes. Otherwise, you run the risk of trapping UA's in the lower level portions of the stack that _REALLY_ need to be propagated to the controlling driver or application. Thanks for the feedback. Unfortunately sending an RSCN is only possible when using Fibre Channel as transport layer. I'm looking for a solution that also works with other SCSI transports, e.g. iSCSI and SRP. And we're already doing that. Rather, the FC HBAs do exactly this. So the proposal would be to export a 'virtual' LUN0 if none is present, so that we always have a device to talk to, right? Shouldn't be too hard; we already create a 'virtual' LUN0 during scanning, only we delete it if no LUNs are found. So we're already doing this, only we don't tell :-) Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/28/2013 9:44 AM, Bart Van Assche wrote: when using Fibre Channel as transport layer. I'm looking for a solution that also works with other SCSI transports, e.g. iSCSI and SRP. Doesn't iSCSI have a SNS server you can subscribe to that provides similar functionality (name services and port add/remove)? SAS has the BROADCAST functionality too which can act as an AEN. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRBp7TAAoJEL5i86xrzcy7jHAIAJlrqG553O0dqiGUFnb+W+oe +KB6SfST0DiqATBJee61kJWw0hzC8EYwDVXgGJnw4c4XqmaAt0JNLPSq8F77DMkC UQzAdz7U8QxrJp9cwdz4HpWiVXolFJ7I6Gg9Og+KBxAMDIWp/mQNa06Y+b0XQgmW /KH4/AJMC+cn5GCYq55cSn+ZmKGO3JVB4tbj1VRgyxF/+dBlfiw94YoHxI6ODvF/ 440Mo1rtI9P5+hdqGlkqxZmjZBzawCWZDHkos75dKIYl332FqrwubBNngL/St8GO 1DGlK6+STDLIE8XyFPhqKLBiObhnKhnZHjtgmGXEw20ZYx7QLd4IPOLLVGdYFik= =PWeG -END PGP SIGNATURE- -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On Mon, 2013-01-28 at 09:52 -0600, Jeremy Linton wrote: On 1/28/2013 9:44 AM, Bart Van Assche wrote: when using Fibre Channel as transport layer. I'm looking for a solution that also works with other SCSI transports, e.g. iSCSI and SRP. Doesn't iSCSI have a SNS server you can subscribe to that provides similar functionality (name services and port add/remove)? SAS has the BROADCAST functionality too which can act as an AEN. I don't think you have to have an iSNS server to use iSCSI, though. It is possible to use Send Targets for discovery. At least that used to be the case. -Ewan -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On 01/28/2013 09:52 AM, Jeremy Linton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/28/2013 9:44 AM, Bart Van Assche wrote: when using Fibre Channel as transport layer. I'm looking for a solution that also works with other SCSI transports, e.g. iSCSI and SRP. Doesn't iSCSI have a SNS server you can subscribe to that provides similar functionality (name services and port add/remove)? SAS has the BROADCAST functionality too which can act as an AEN. iSCSI does have a SNS server. In iSCSI it is called iSNS. The problem is that it is not widely used. -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On Mon, 2013-01-28 at 16:48 +0100, Hannes Reinecke wrote: On 01/28/2013 04:44 PM, Bart Van Assche wrote: On 01/28/13 16:05, Jeremy Linton wrote: What I think your looking for is RSCN (Registered State Change notification). Hook that, and then check the name server. This will tell you when ports get added/removed. You can then report luns against lun 0 of all the known target ports. This allows you to transparently detect changes. Otherwise, you run the risk of trapping UA's in the lower level portions of the stack that _REALLY_ need to be propagated to the controlling driver or application. Thanks for the feedback. Unfortunately sending an RSCN is only possible when using Fibre Channel as transport layer. I'm looking for a solution that also works with other SCSI transports, e.g. iSCSI and SRP. And we're already doing that. Rather, the FC HBAs do exactly this. So the proposal would be to export a 'virtual' LUN0 if none is present, so that we always have a device to talk to, right? Shouldn't be too hard; we already create a 'virtual' LUN0 during scanning, only we delete it if no LUNs are found. So we're already doing this, only we don't tell :-) I'm not sure I'd like to leave virtual LUN-0 around if we find nothing because it's going to cause confusion and be nasty in cases where a physical lun 0 is created later. However, don't the standards define this ignored lun: W-LUN that's supposed to be created precisely for this purpose? I wouldn't object to creating and exporting one of those if we have to and the array doesn't supply it. James -- 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
RE: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
-Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- ow...@vger.kernel.org] On Behalf Of Jeremy Linton Sent: Monday, January 28, 2013 10:05 AM To: Bart Van Assche Cc: Hannes Reinecke; Ewan D. Milne; linux-scsi@vger.kernel.org Subject: Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/24/2013 8:38 AM, Bart Van Assche wrote: Let me ask this another way. SAN users expect that the LUN list at the initiator side gets updated automatically after a SAN configuration change. How should a SAN system communicate to a SCSI initiator that the LUN list has been changed ? Some FC SAN systems send a LIP after a configuration change to force the initiator to rescan LUNs. But how to What I think your looking for is RSCN (Registered State Change notification) . Hook that, and then check the name server. This will tell you when ports get added/removed. You can then report luns against lun 0 of all the known target ports. This allows you to transparently detect changes. iSNS based SCN registrations - Open iSCSI facilitates a subset of such SCNs. http://linux.dell.com/files/presentations/Red_Hat_Summit_2009/Simplifying_Linux_iSCSI_management_with_iSNS-v0.7.pdf Now if you want SCSI to do SCN registrations that will be a topic to discuss.. though I would say we don't go down that path.. Since both FC/FCoE and iSCSI can register with an iSNS/SNS server this should solve it atleast for the login/logout scenario. -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On 01/26/2013 07:20 PM, Mike Christie wrote: On 01/24/2013 09:15 AM, Hannes Reinecke wrote: On 01/24/2013 04:00 PM, Mike Christie wrote: On 01/24/2013 07:51 AM, Hannes Reinecke wrote: On 01/24/2013 03:38 PM, Bart Van Assche wrote: On Thu, Jan 24, 2013 at 4:38 AM, Hannes Reinecke h...@suse.de wrote: As for AEN, does iSCSI _do_ AEN? I thought it got removed ... If it does, though, it should schedule an event on its own whenever an AER is received. The same goes for LLDDs with vendor-specific AENs; thinking of megaraid_sas here ... Let me ask this another way. SAN users expect that the LUN list at the initiator side gets updated automatically after a SAN configuration change. How should a SAN system communicate to a SCSI initiator that the LUN list has been changed ? Some FC SAN systems send a LIP after a configuration change to force the initiator to rescan LUNs. And thereby disrupting traffic on _ALL_ LUNs on the loop. Really cool idea. I know; the one vendor which does _not_ talk to us. But how to inform the initiator about a LUN change for other SCSI protocols ? I'm not sure that it is even possible to report such a change via sense data in case a SAN user first removes all LUNs and after that change adds one or more LUNs. The official way is indeed via UAs; most storage arrays (Hello, NetApp!) provide a default LUN0 which is always visible. Up to the point that some even refuse to add 'normal' disk LUNs to LUN0. Or have the ominous 'Well-known Address' LUN to handle these kind of issues. Obviously, one needs to send commands to it to even _get_ an UA back. In SAM5 there is that QUERY ASYNCHRONOUS EVENT TMF. Could we send that periodically to lun0/well-knwon-lun if the transport supports it (iscsi will in http://tools.ietf.org/html/draft-ietf-storm-iscsi-sam-06#section-6). Whatever daemon in userspace handles these other events, could send it (we just need to add a interface) or we could add kernel code. Oh, cool. Polling a device to figure out if we should poll it :-) We'd be better off sending TEST UNIT READY to it; then we should be getting UAs regardless on the SAM version in use on the target. To handle the case where all devices are removed then new ones are added, we will not have kernel structs or /dev/sdXs to send TURs to to find new ones. Are you thinking we would do something like have the kernel create temp structs to send TURs to LUN0/well-known-lun? Or, do you think we would have something doing scsi scans (call scsi_scan_target or scsi_scan_host) every once in a while? Well, not as such. Most arrays (eg RDAC, EVA, or EMC) will present you with a separate device (like the infamous 'Universal Xport' :-) which will be present always, so it can be used for polling in case no targets are present. NetApp and the like are more tricky as they do _not_ present any targets per default. So we'd need something here to talk to. Some kind of 'virtual' LUN0 or somesuch. Wouldn't this be a grand topic for LSF? Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On 01/24/2013 09:15 AM, Hannes Reinecke wrote: On 01/24/2013 04:00 PM, Mike Christie wrote: On 01/24/2013 07:51 AM, Hannes Reinecke wrote: On 01/24/2013 03:38 PM, Bart Van Assche wrote: On Thu, Jan 24, 2013 at 4:38 AM, Hannes Reinecke h...@suse.de wrote: As for AEN, does iSCSI _do_ AEN? I thought it got removed ... If it does, though, it should schedule an event on its own whenever an AER is received. The same goes for LLDDs with vendor-specific AENs; thinking of megaraid_sas here ... Let me ask this another way. SAN users expect that the LUN list at the initiator side gets updated automatically after a SAN configuration change. How should a SAN system communicate to a SCSI initiator that the LUN list has been changed ? Some FC SAN systems send a LIP after a configuration change to force the initiator to rescan LUNs. And thereby disrupting traffic on _ALL_ LUNs on the loop. Really cool idea. I know; the one vendor which does _not_ talk to us. But how to inform the initiator about a LUN change for other SCSI protocols ? I'm not sure that it is even possible to report such a change via sense data in case a SAN user first removes all LUNs and after that change adds one or more LUNs. The official way is indeed via UAs; most storage arrays (Hello, NetApp!) provide a default LUN0 which is always visible. Up to the point that some even refuse to add 'normal' disk LUNs to LUN0. Or have the ominous 'Well-known Address' LUN to handle these kind of issues. Obviously, one needs to send commands to it to even _get_ an UA back. In SAM5 there is that QUERY ASYNCHRONOUS EVENT TMF. Could we send that periodically to lun0/well-knwon-lun if the transport supports it (iscsi will in http://tools.ietf.org/html/draft-ietf-storm-iscsi-sam-06#section-6). Whatever daemon in userspace handles these other events, could send it (we just need to add a interface) or we could add kernel code. Oh, cool. Polling a device to figure out if we should poll it :-) We'd be better off sending TEST UNIT READY to it; then we should be getting UAs regardless on the SAM version in use on the target. To handle the case where all devices are removed then new ones are added, we will not have kernel structs or /dev/sdXs to send TURs to to find new ones. Are you thinking we would do something like have the kernel create temp structs to send TURs to LUN0/well-known-lun? Or, do you think we would have something doing scsi scans (call scsi_scan_target or scsi_scan_host) every once in a while? -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On 01/24/2013 01:19 AM, Bart Van Assche wrote: On Fri, Jan 18, 2013 at 9:27 AM, Ewan D. Milne emi...@redhat.com wrote: This patch set adds changes to the SCSI mid-layer, sysfs and scsi_debug to provide enhanced support for Unit Attention conditions, as well as detection of reported sense data overflow conditions and some changes to sense data processing. It also adds a uevent when the reported capacity changes on an sd device. There was some discussion about this a couple of years ago on the linux-scsi mailing list: http://marc.info/?l=linux-scsim=129702506514742w=2 Although one approach is to send all SCSI sense data to a userspace daemon for processing, this patch set does not take that approach due to the difficulty in reliably delivering all of the data. An interesting UA condition might not be delivered due to a flood of media errors, for example. 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. Does this patch series add a function that allows SCSI LLDs to report AEN data to the SCSI core ? What if a SCSI target reports a LUN inventory change via AER to e.g. the iSCSI initiator and that initiator ignores the AEN data ? Will that result in AEN data being ignored and no automatic LUN rescanning ? Well, first and foremost we _don't_ have automatic LUN rescanning. This patchset just puts in the infrastructure that userspace can know _when_ a LUN rescan might be in order. As for AEN, does iSCSI _do_ AEN? I thought it got removed ... If it does, though, it should schedule an event on its own whenever an AER is received. The same goes for LLDDs with vendor-specific AENs; thinking of megaraid_sas here ... Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On Wed, 2013-01-23 at 17:19 -0700, Bart Van Assche wrote: On Fri, Jan 18, 2013 at 9:27 AM, Ewan D. Milne emi...@redhat.com wrote: This patch set adds changes to the SCSI mid-layer, sysfs and scsi_debug to provide enhanced support for Unit Attention conditions, as well as detection of reported sense data overflow conditions and some changes to sense data processing. It also adds a uevent when the reported capacity changes on an sd device. There was some discussion about this a couple of years ago on the linux-scsi mailing list: http://marc.info/?l=linux-scsim=129702506514742w=2 Although one approach is to send all SCSI sense data to a userspace daemon for processing, this patch set does not take that approach due to the difficulty in reliably delivering all of the data. An interesting UA condition might not be delivered due to a flood of media errors, for example. 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. Does this patch series add a function that allows SCSI LLDs to report AEN data to the SCSI core ? What if a SCSI target reports a LUN inventory change via AER to e.g. the iSCSI initiator and that initiator ignores the AEN data ? Will that result in AEN data being ignored and no automatic LUN rescanning ? Well, what the patch series does is add handling in scsi_check_sense(), so any sense processing that went through that path would be handled. I don't think this would apply to AEN, however. The only AEN handling that I am aware of was in iscsi-initiator-utils, in userspace, which did a rescan on the iscsi session when a 3F 0E code was received. Bart. -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On Thu, 2013-01-24 at 12:38 +0100, Hannes Reinecke wrote: On 01/24/2013 01:19 AM, Bart Van Assche wrote: On Fri, Jan 18, 2013 at 9:27 AM, Ewan D. Milne emi...@redhat.com wrote: This patch set adds changes to the SCSI mid-layer, sysfs and scsi_debug to provide enhanced support for Unit Attention conditions, as well as detection of reported sense data overflow conditions and some changes to sense data processing. It also adds a uevent when the reported capacity changes on an sd device. There was some discussion about this a couple of years ago on the linux-scsi mailing list: http://marc.info/?l=linux-scsim=129702506514742w=2 Although one approach is to send all SCSI sense data to a userspace daemon for processing, this patch set does not take that approach due to the difficulty in reliably delivering all of the data. An interesting UA condition might not be delivered due to a flood of media errors, for example. 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. Does this patch series add a function that allows SCSI LLDs to report AEN data to the SCSI core ? What if a SCSI target reports a LUN inventory change via AER to e.g. the iSCSI initiator and that initiator ignores the AEN data ? Will that result in AEN data being ignored and no automatic LUN rescanning ? Well, first and foremost we _don't_ have automatic LUN rescanning. This patchset just puts in the infrastructure that userspace can know _when_ a LUN rescan might be in order. As for AEN, does iSCSI _do_ AEN? I thought it got removed ... I think you are right, I think AEN was removed in SAM-3 (sam3r14, if my sources are correct). Bart might have a point, though. I wonder if an iscsi device conforming to SAM-2 would report a LUN inventory change via AEN, but not as a UA on a normal SCSI command, in which case the iscsi initiator would have to handle it. I'll have to do some research and probably ask some vendors about that, it could maybe be addressed with a follow-on patch. If it does, though, it should schedule an event on its own whenever an AER is received. The same goes for LLDDs with vendor-specific AENs; thinking of megaraid_sas here ... Cheers, Hannes -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On 01/24/2013 04:38 AM, Hannes Reinecke wrote: On 01/24/2013 01:19 AM, Bart Van Assche wrote: On Fri, Jan 18, 2013 at 9:27 AM, Ewan D. Milne emi...@redhat.com wrote: This patch set adds changes to the SCSI mid-layer, sysfs and scsi_debug to provide enhanced support for Unit Attention conditions, as well as detection of reported sense data overflow conditions and some changes to sense data processing. It also adds a uevent when the reported capacity changes on an sd device. There was some discussion about this a couple of years ago on the linux-scsi mailing list: http://marc.info/?l=linux-scsim=129702506514742w=2 Although one approach is to send all SCSI sense data to a userspace daemon for processing, this patch set does not take that approach due to the difficulty in reliably delivering all of the data. An interesting UA condition might not be delivered due to a flood of media errors, for example. 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. Does this patch series add a function that allows SCSI LLDs to report AEN data to the SCSI core ? What if a SCSI target reports a LUN inventory change via AER to e.g. the iSCSI initiator and that initiator ignores the AEN data ? Will that result in AEN data being ignored and no automatic LUN rescanning ? Well, first and foremost we _don't_ have automatic LUN rescanning. This patchset just puts in the infrastructure that userspace can know _when_ a LUN rescan might be in order. As for AEN, does iSCSI _do_ AEN? I thought it got removed ... The AEN is sent to userspace right now. If it does, though, it should schedule an event on its own whenever an AER is received. The same goes for LLDDs with vendor-specific AENs; thinking of megaraid_sas here ... Yeah. It would be nicer if there was a wrapper around this code: +#ifdef CONFIG_SCSI_ENHANCED_UA + struct scsi_target *starget = scsi_target(sdev); + if (atomic_xchg(starget-lun_change_reported, 1) == 0) + schedule_delayed_work(starget-ua_dwork, 2*HZ); + scmd_printk(KERN_WARNING, scmd, + Reported LUNs data has changed); +#else so drivers do not have to have to duplicate and know that low level of details. -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On Thu, Jan 24, 2013 at 4:38 AM, Hannes Reinecke h...@suse.de wrote: As for AEN, does iSCSI _do_ AEN? I thought it got removed ... If it does, though, it should schedule an event on its own whenever an AER is received. The same goes for LLDDs with vendor-specific AENs; thinking of megaraid_sas here ... Let me ask this another way. SAN users expect that the LUN list at the initiator side gets updated automatically after a SAN configuration change. How should a SAN system communicate to a SCSI initiator that the LUN list has been changed ? Some FC SAN systems send a LIP after a configuration change to force the initiator to rescan LUNs. But how to inform the initiator about a LUN change for other SCSI protocols ? I'm not sure that it is even possible to report such a change via sense data in case a SAN user first removes all LUNs and after that change adds one or more LUNs. Bart. -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On 01/24/2013 03:38 PM, Bart Van Assche wrote: On Thu, Jan 24, 2013 at 4:38 AM, Hannes Reinecke h...@suse.de wrote: As for AEN, does iSCSI _do_ AEN? I thought it got removed ... If it does, though, it should schedule an event on its own whenever an AER is received. The same goes for LLDDs with vendor-specific AENs; thinking of megaraid_sas here ... Let me ask this another way. SAN users expect that the LUN list at the initiator side gets updated automatically after a SAN configuration change. How should a SAN system communicate to a SCSI initiator that the LUN list has been changed ? Some FC SAN systems send a LIP after a configuration change to force the initiator to rescan LUNs. And thereby disrupting traffic on _ALL_ LUNs on the loop. Really cool idea. I know; the one vendor which does _not_ talk to us. But how to inform the initiator about a LUN change for other SCSI protocols ? I'm not sure that it is even possible to report such a change via sense data in case a SAN user first removes all LUNs and after that change adds one or more LUNs. The official way is indeed via UAs; most storage arrays (Hello, NetApp!) provide a default LUN0 which is always visible. Up to the point that some even refuse to add 'normal' disk LUNs to LUN0. Or have the ominous 'Well-known Address' LUN to handle these kind of issues. Obviously, one needs to send commands to it to even _get_ an UA back. But yeah, normally it's possible. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On 01/24/2013 07:51 AM, Hannes Reinecke wrote: On 01/24/2013 03:38 PM, Bart Van Assche wrote: On Thu, Jan 24, 2013 at 4:38 AM, Hannes Reinecke h...@suse.de wrote: As for AEN, does iSCSI _do_ AEN? I thought it got removed ... If it does, though, it should schedule an event on its own whenever an AER is received. The same goes for LLDDs with vendor-specific AENs; thinking of megaraid_sas here ... Let me ask this another way. SAN users expect that the LUN list at the initiator side gets updated automatically after a SAN configuration change. How should a SAN system communicate to a SCSI initiator that the LUN list has been changed ? Some FC SAN systems send a LIP after a configuration change to force the initiator to rescan LUNs. And thereby disrupting traffic on _ALL_ LUNs on the loop. Really cool idea. I know; the one vendor which does _not_ talk to us. But how to inform the initiator about a LUN change for other SCSI protocols ? I'm not sure that it is even possible to report such a change via sense data in case a SAN user first removes all LUNs and after that change adds one or more LUNs. The official way is indeed via UAs; most storage arrays (Hello, NetApp!) provide a default LUN0 which is always visible. Up to the point that some even refuse to add 'normal' disk LUNs to LUN0. Or have the ominous 'Well-known Address' LUN to handle these kind of issues. Obviously, one needs to send commands to it to even _get_ an UA back. In SAM5 there is that QUERY ASYNCHRONOUS EVENT TMF. Could we send that periodically to lun0/well-knwon-lun if the transport supports it (iscsi will in http://tools.ietf.org/html/draft-ietf-storm-iscsi-sam-06#section-6). Whatever daemon in userspace handles these other events, could send it (we just need to add a interface) or we could add kernel code. This should not hold up Ewan's patches though. -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On 01/24/2013 04:00 PM, Mike Christie wrote: On 01/24/2013 07:51 AM, Hannes Reinecke wrote: On 01/24/2013 03:38 PM, Bart Van Assche wrote: On Thu, Jan 24, 2013 at 4:38 AM, Hannes Reinecke h...@suse.de wrote: As for AEN, does iSCSI _do_ AEN? I thought it got removed ... If it does, though, it should schedule an event on its own whenever an AER is received. The same goes for LLDDs with vendor-specific AENs; thinking of megaraid_sas here ... Let me ask this another way. SAN users expect that the LUN list at the initiator side gets updated automatically after a SAN configuration change. How should a SAN system communicate to a SCSI initiator that the LUN list has been changed ? Some FC SAN systems send a LIP after a configuration change to force the initiator to rescan LUNs. And thereby disrupting traffic on _ALL_ LUNs on the loop. Really cool idea. I know; the one vendor which does _not_ talk to us. But how to inform the initiator about a LUN change for other SCSI protocols ? I'm not sure that it is even possible to report such a change via sense data in case a SAN user first removes all LUNs and after that change adds one or more LUNs. The official way is indeed via UAs; most storage arrays (Hello, NetApp!) provide a default LUN0 which is always visible. Up to the point that some even refuse to add 'normal' disk LUNs to LUN0. Or have the ominous 'Well-known Address' LUN to handle these kind of issues. Obviously, one needs to send commands to it to even _get_ an UA back. In SAM5 there is that QUERY ASYNCHRONOUS EVENT TMF. Could we send that periodically to lun0/well-knwon-lun if the transport supports it (iscsi will in http://tools.ietf.org/html/draft-ietf-storm-iscsi-sam-06#section-6). Whatever daemon in userspace handles these other events, could send it (we just need to add a interface) or we could add kernel code. Oh, cool. Polling a device to figure out if we should poll it :-) We'd be better off sending TEST UNIT READY to it; then we should be getting UAs regardless on the SAM version in use on the target. (Especially as some target lie about the supported version, so they might be supporting SAM-5 without telling us ...) This should not hold up Ewan's patches though. Correct. AEN handling discussion is a different story and should be build on top of Ewans patches. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On Thu, 2013-01-24 at 16:15 +0100, Hannes Reinecke wrote: On 01/24/2013 04:00 PM, Mike Christie wrote: On 01/24/2013 07:51 AM, Hannes Reinecke wrote: On 01/24/2013 03:38 PM, Bart Van Assche wrote: On Thu, Jan 24, 2013 at 4:38 AM, Hannes Reinecke h...@suse.de wrote: As for AEN, does iSCSI _do_ AEN? I thought it got removed ... If it does, though, it should schedule an event on its own whenever an AER is received. The same goes for LLDDs with vendor-specific AENs; thinking of megaraid_sas here ... Let me ask this another way. SAN users expect that the LUN list at the initiator side gets updated automatically after a SAN configuration change. How should a SAN system communicate to a SCSI initiator that the LUN list has been changed ? Some FC SAN systems send a LIP after a configuration change to force the initiator to rescan LUNs. And thereby disrupting traffic on _ALL_ LUNs on the loop. Really cool idea. I know; the one vendor which does _not_ talk to us. But how to inform the initiator about a LUN change for other SCSI protocols ? I'm not sure that it is even possible to report such a change via sense data in case a SAN user first removes all LUNs and after that change adds one or more LUNs. The official way is indeed via UAs; most storage arrays (Hello, NetApp!) provide a default LUN0 which is always visible. Up to the point that some even refuse to add 'normal' disk LUNs to LUN0. Or have the ominous 'Well-known Address' LUN to handle these kind of issues. Obviously, one needs to send commands to it to even _get_ an UA back. In SAM5 there is that QUERY ASYNCHRONOUS EVENT TMF. Could we send that periodically to lun0/well-knwon-lun if the transport supports it (iscsi will in http://tools.ietf.org/html/draft-ietf-storm-iscsi-sam-06#section-6). Whatever daemon in userspace handles these other events, could send it (we just need to add a interface) or we could add kernel code. Oh, cool. Polling a device to figure out if we should poll it :-) We'd be better off sending TEST UNIT READY to it; then we should be getting UAs regardless on the SAM version in use on the target. I believe that multipath is already sending periodic commands to devices through the different paths, to determine up-to-date path status. So, in at least some cases, we wouldn't have to do anything else. (Especially as some target lie about the supported version, so they might be supporting SAM-5 without telling us ...) This should not hold up Ewan's patches though. Correct. AEN handling discussion is a different story and should be build on top of Ewans patches. Cheers, Hannes -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On Thu, 2013-01-24 at 07:01 -0700, Mike Christie wrote: On 01/24/2013 04:38 AM, Hannes Reinecke wrote: On 01/24/2013 01:19 AM, Bart Van Assche wrote: On Fri, Jan 18, 2013 at 9:27 AM, Ewan D. Milne emi...@redhat.com wrote: This patch set adds changes to the SCSI mid-layer, sysfs and scsi_debug to provide enhanced support for Unit Attention conditions, as well as detection of reported sense data overflow conditions and some changes to sense data processing. It also adds a uevent when the reported capacity changes on an sd device. There was some discussion about this a couple of years ago on the linux-scsi mailing list: http://marc.info/?l=linux-scsim=129702506514742w=2 Although one approach is to send all SCSI sense data to a userspace daemon for processing, this patch set does not take that approach due to the difficulty in reliably delivering all of the data. An interesting UA condition might not be delivered due to a flood of media errors, for example. 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. Does this patch series add a function that allows SCSI LLDs to report AEN data to the SCSI core ? What if a SCSI target reports a LUN inventory change via AER to e.g. the iSCSI initiator and that initiator ignores the AEN data ? Will that result in AEN data being ignored and no automatic LUN rescanning ? Well, first and foremost we _don't_ have automatic LUN rescanning. This patchset just puts in the infrastructure that userspace can know _when_ a LUN rescan might be in order. As for AEN, does iSCSI _do_ AEN? I thought it got removed ... The AEN is sent to userspace right now. If it does, though, it should schedule an event on its own whenever an AER is received. The same goes for LLDDs with vendor-specific AENs; thinking of megaraid_sas here ... Yeah. It would be nicer if there was a wrapper around this code: +#ifdef CONFIG_SCSI_ENHANCED_UA + struct scsi_target *starget = scsi_target(sdev); + if (atomic_xchg(starget-lun_change_reported, 1) == 0) + schedule_delayed_work(starget-ua_dwork, 2*HZ); + scmd_printk(KERN_WARNING, scmd, + Reported LUNs data has changed); +#else so drivers do not have to have to duplicate and know that low level of details. I could move that to an exported function. I guess the questions would be (a) is this the only ASC/ASCQ combination that should be available in that way, and (b) should it be conditional on the config option? Thanks for your comments. -- 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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On 01/24/2013 03:02 PM, Ewan Milne wrote:
On Thu, 2013-01-24 at 07:01 -0700, Mike Christie wrote:
On 01/24/2013 04:38 AM, Hannes Reinecke wrote:
On 01/24/2013 01:19 AM, Bart Van Assche wrote:
On Fri, Jan 18, 2013 at 9:27 AM, Ewan D. Milne emi...@redhat.com wrote:
This patch set adds changes to the SCSI mid-layer, sysfs and scsi_debug
to provide enhanced support for Unit Attention conditions, as well as
detection of reported sense data overflow conditions and some changes
to sense data processing. It also adds a uevent when the reported
capacity changes on an sd device.
There was some discussion about this a couple of years ago on the
linux-scsi
mailing list: http://marc.info/?l=linux-scsim=129702506514742w=2
Although one approach is to send all SCSI sense data to a userspace
daemon
for processing, this patch set does not take that approach due to the
difficulty in reliably delivering all of the data. An interesting UA
condition might not be delivered due to a flood of media errors, for
example.
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.
Does this patch series add a function that allows SCSI LLDs to report
AEN data to the SCSI core ? What if a SCSI target reports a LUN
inventory change via AER to e.g. the iSCSI initiator and that
initiator ignores the AEN data ? Will that result in AEN data being
ignored and no automatic LUN rescanning ?
Well, first and foremost we _don't_ have automatic LUN rescanning.
This patchset just puts in the infrastructure that userspace can know
_when_ a LUN rescan might be in order.
As for AEN, does iSCSI _do_ AEN? I thought it got removed ...
The AEN is sent to userspace right now.
If it does, though, it should schedule an event on its own whenever an
AER is received. The same goes for LLDDs with vendor-specific AENs;
thinking of megaraid_sas here ...
Yeah. It would be nicer if there was a wrapper around this code:
+#ifdef CONFIG_SCSI_ENHANCED_UA
+struct scsi_target *starget = scsi_target(sdev);
+if (atomic_xchg(starget-lun_change_reported, 1) == 0)
+schedule_delayed_work(starget-ua_dwork, 2*HZ);
+scmd_printk(KERN_WARNING, scmd,
+Reported LUNs data has changed);
+#else
so drivers do not have to have to duplicate and know that low level of
details.
I could move that to an exported function. I guess the questions would
be (a) is this the only ASC/ASCQ combination that should be available
in that way, and (b) should it be conditional on the config option?
A. There are others. Basically anything that is handled in patch 6.
B. I think you want to make a scsi_check_sense function that
scsi_error.c calls and drivers can call. It would take a sshdr. That
core function would then do all this. So it would basically be like:
static int scsi_check_cmd_sense(struct scsi_cmnd *scmd)
{
struct scsi_sense_hdr sshdr;
if (!scsi_command_normalize_sense(scmd, sshdr))
return FAILED; /* no valid sense data */
if (scmd-cmnd[0] == TEST_UNIT_READY scmd-scsi_done !=
scsi_eh_done)
/*
* nasty: for mid-layer issued TURs, we need to return the
* actual sense data without any recovery attempt. For eh
* issued ones, we need to try to recover and interpret
*/
return SUCCESS;
return scsi_check_sense(sshdr);
}
// other drivers that get sense not in a scsi command can then call this.
int scsi_check_sense(struct scsi_device *sdev, struct scsi_sense_hdr
sshdr, sense_buffer)
{
This is basically the scsi_check_sense we have today but below the cmd
related checks above.
}
Also, scsi_dh_alua is checking for report luns data has changed and
inquiry data has changed. That code should be removed or if alua is used
then we will not hit your new schedule work code paths.
--
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
Re: [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
On Fri, Jan 18, 2013 at 9:27 AM, Ewan D. Milne emi...@redhat.com wrote: This patch set adds changes to the SCSI mid-layer, sysfs and scsi_debug to provide enhanced support for Unit Attention conditions, as well as detection of reported sense data overflow conditions and some changes to sense data processing. It also adds a uevent when the reported capacity changes on an sd device. There was some discussion about this a couple of years ago on the linux-scsi mailing list: http://marc.info/?l=linux-scsim=129702506514742w=2 Although one approach is to send all SCSI sense data to a userspace daemon for processing, this patch set does not take that approach due to the difficulty in reliably delivering all of the data. An interesting UA condition might not be delivered due to a flood of media errors, for example. 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. Does this patch series add a function that allows SCSI LLDs to report AEN data to the SCSI core ? What if a SCSI target reports a LUN inventory change via AER to e.g. the iSCSI initiator and that initiator ignores the AEN data ? Will that result in AEN data being ignored and no automatic LUN rescanning ? Bart. -- 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
[PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling
From: Ewan D. Milne emi...@redhat.com This patch set adds changes to the SCSI mid-layer, sysfs and scsi_debug to provide enhanced support for Unit Attention conditions, as well as detection of reported sense data overflow conditions and some changes to sense data processing. It also adds a uevent when the reported capacity changes on an sd device. There was some discussion about this a couple of years ago on the linux-scsi mailing list: http://marc.info/?l=linux-scsim=129702506514742w=2 Although one approach is to send all SCSI sense data to a userspace daemon for processing, this patch set does not take that approach due to the difficulty in reliably delivering all of the data. An interesting UA condition might not be delivered due to a flood of media errors, for example. 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. The changes are (mostly) enabled by a new kernel config option CONFIG_SCSI_ENHANCED_UA. If this config option is not used, no new uevents are generated. There are some changes to kernel logging messages if CONFIG_SCSI_ENHANCED_UA is enabled, because the existing messages explicitly stated that the kernel did not do anything with the information. Note that checkpatch is reporting errors on patch 7/9 relating to macros in scsi_sysfs.c -- I believe these errors are incorrect and have sent a message to the checkpatch maintainer. The macros were derived from existing ones already in the file. Ewan D. Milne (9): [SCSI] Detect overflow of sense data buffer [SCSI] Generate uevent on sd capacity change [SCSI] Add a kernel config option for enhanced Unit Attention support [SCSI] Rename scsi_evt_xxx to sdev_evt_xxx and scsi_event to sdev_event [SCSI] Add support for scsi_target events [SCSI] Generate uevents for certain Unit Attention codes [SCSI] Add sysfs support for enhanced Unit Attention handling [SCSI] Add sense and Unit Attention generation to scsi_debug [SCSI] Streamline detection of FM/EOM/ILI status drivers/scsi/Kconfig | 12 +++ drivers/scsi/scsi_debug.c | 168 ++ drivers/scsi/scsi_error.c | 198 - drivers/scsi/scsi_lib.c| 178 +--- drivers/scsi/scsi_priv.h | 10 ++- drivers/scsi/scsi_scan.c | 54 ++--- drivers/scsi/scsi_sysfs.c | 148 ++--- drivers/scsi/sd.c | 9 +++ include/scsi/scsi_cmnd.h | 4 + include/scsi/scsi_device.h | 64 ++- include/scsi/scsi_eh.h | 7 ++ 11 files changed, 773 insertions(+), 79 deletions(-) -- 1.7.11.7 -- 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
