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):
Steps to Reproduce:
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
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.
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.