Re: [PATCH v2 0/8] [SCSI] Enhanced sense and Unit Attention handling
On Thu, 2013-04-11 at 16:52 -0500, Jeremy Linton wrote: 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. I haven't heard back about it. If some people would ACK it I think that would help. I also submitted a separate patch for automatic LUN removal. 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? Well, the patch does that, among other things. I think handling the other UA codes is a good idea, because existing LUNs can be reconfigured. Coalescing events in the kernel is necessary because udev couldn't handle a large number of events from a big storage configuration. A really fancy patch could attempt to clear the check conditions from LUNs that share the I_T. I think the mid-layer will handle that automatically. If check conditions are reported the commands will have to be reissued. -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 v2 0/8] [SCSI] Enhanced sense and Unit Attention handling
On 4/15/2013 9:13 AM, Ewan Milne wrote: patch could attempt to clear the check conditions from LUNs that share the I_T. I think the mid-layer will handle that automatically. If check conditions are reported the commands will have to be reissued. But, not automatically (unless i'm missing something again). The UA is going to arrive when each lun gets sent a command, which could be a long time from the initial UA if the lun is idle. Enough time, that the attempts to coalesce the events are going to fail. I guess it depends on what you have udev doing when it gets the event. If it triggers a rescan involving something besides inquiry/report luns then that will trigger the remaining UA's from the luns on the target that changed. But if it does something other than that, I don't see it by reading the patch/scsi_scan.c code. -- 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 v2 0/8] [SCSI] Enhanced sense and Unit Attention handling
On Mon, 2013-04-15 at 11:20 -0500, Jeremy Linton wrote: On 4/15/2013 9:13 AM, Ewan Milne wrote: patch could attempt to clear the check conditions from LUNs that share the I_T. I think the mid-layer will handle that automatically. If check conditions are reported the commands will have to be reissued. But, not automatically (unless i'm missing something again). The UA is going to arrive when each lun gets sent a command, which could be a long time from the initial UA if the lun is idle. Enough time, that the attempts to coalesce the events are going to fail. Yes, although we can't put off rescanning for too long, or the system won't react in a timely manner to a storage configuration change. I used 2 seconds which was a compromise to avoid overloading udev. If the UAs are received too far apart in time, then more than one event will be generated. Note, if multipath is in use, multipathd will periodically (every 15 seconds, I think) send commands to all the paths, so the UAs will be detected at that point. I guess it depends on what you have udev doing when it gets the event. If it triggers a rescan involving something besides inquiry/report luns then that will trigger the remaining UA's from the luns on the target that changed. But if it does something other than that, I don't see it by reading the patch/scsi_scan.c code. What I did in my testing was have a udev rule that performed a rescan. I believe sd_revalidate_disk() ends up being called, which will perform several commands (MODE SENSE, READ CAPACITY, etc.), for disk devices. -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 v2 0/8] [SCSI] Enhanced sense and Unit Attention handling
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
[PATCH v2 0/8] [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 6/8 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. Some changes have been made to this patch set since an earlier version was sent out with RFC: - Remove patch 1/9 Detect overflow of sense data buffer Some scsi_debug changes in this patch were moved to patch 7/8 - Corrected Kconfig help text - 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 Thanks to everyone for the comments on this patch series. Ewan D. Milne (8): [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 | 138 ++ drivers/scsi/scsi_error.c | 203 - drivers/scsi/scsi_lib.c| 180 +--- 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 | 8 ++ 11 files changed, 750 insertions(+), 80 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
