Description of problem: The features field of the hwentry structure in the hwtable vector setup in libmultipath/hwtable.c needs to be set to "1 queue_if_no_path" for the EMC CLARiion. This field is currently set to 0. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
EMC CLARiion needs this multipath feature enabled in order to not fail ios during expected transient periods when all paths to a CLARiion logical unit are failed as part of a non-destructive upgrade of the CLARiion storage system's ucode.
Ed, while I'm willing to add that flag for the EMC CX series, could you please check with your CX group about _why_ the CLARiiON is violating the written specification of _not_ requiring this during a NDU? Maybe it's a pending firmware bug in the CX; if not, one should be filed for it too; either the firmware or the documentation needs fixing. I think your customers would appreciate that ;-)
During an NDU of CLARiiON ucode the CLARiiON's write cache must be written to safe storage on the CLARiiON and the data in the safe processed. During some portion of this time, both SPs can be non-respondent to any IO from an attached host. If this period of time is longer than a linux host's SCSI command timeout, the SCSI layer will report a command timeout. This will cause the multipathing software to fail a path and retry on another path to the same logical unit. Assuming this process is repeated for all paths to the same logical unit, all paths the logical unit will be in a failed state. The only thing keeping an IO error (ENXIO) from being propagated to the user is the queue_if_no_path multipath attribute.
Would you please provide an update to this Bugzilla? Has this request been accepted and will the change be incorporated into RHEL 4.0 U3? If additional information is required from EMC, please let me know. Thanks. Heather
AFAIK, this change request made it into Red Hat AS 4 Update 2.
This bugzilla should be closed as resolved as per comment #5 above.
Closed per confirmation from EMC comments #5 & #7. Never released w/ the bug.