Mike Christie wrote: > Mike Christie wrote: >>> For starters we just should send a netlink event when fast_fail_io has >>> fired. We could easily integrate that one in multipathd and would gain >>> an instant benefit from that as we can switch paths in advance. >>> Next step would be to implement an additional sdev state which would >>> return 'DID_TRANSPORT_FASTFAIL' for any 'normal' I/O; it would be >>> inserted between 'RUNNING' and 'CANCEL'. >>> Transition would be possible between 'RUNNING' and 'FASTFAIL', but >>> it would only be possible to transition into 'CANCEL' from 'FASTFAIL'. >>> >> >> >> Yeah, a new sdev state might be nice. Right now this state is handled >> by the classes. For iscsi and FC the port/session will be in >> blocked/ISCSI_SESSION_FAILED. Then internally the classes are >> decieding what to do with IO in the *_chkready functions. >> >> > > > How about setting the device to the offline state for this case where > fast_io_fail has fired but the dev_loss_tmo has not yet fired? As fast > as failing IO we get the same result. scsi-ml would fail the incoming IO > instead of it getting to the class _chkready functions, but the scsi > device state indicates that it cannot execute IO which might be nice for > users. > Ah, no. OFFLINE is a dead end status out of which we cannot transition from inside the kernel. I'd prefer a new state here. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
