On 03/14/2013 07:09 PM, Steffen Maier wrote:
Just for my understanding:
So this is a bit like writing 0 into the failed attribute of a
zfcp_port in sysfs (zfcp_sysfs_port_failed_store()) which forces a
port reopen recovery including a sequence of fc_remote_port_delete
and fc_remote_port_add?
Sorta.
This patch simulates the result of an RSCN where this remote port is missing. So the fast_io_fail / dev_loss_tmo mechanism is triggered (until further notice). It'll be reset with the next RSCN or by manually resetting the port state.

If so, it sounds good to have this functionality for any FC LLD in
common code.

That's why I posted this code :-)
Rationale for this patch is a weird test case with brocade switches;
there you can actually disable a _target_ port. So the port isn't
reachable anymore but no RSCN is send.
And the LLDD is forced into error recovery which'll take _ages_ as each and every command send during error recovery will time out.

(And I can think about deprecating parts of zfcp code, next we could
consider the same for zfcp's forced LUN and adapter recovery or
maybe this already exists as sdev's writable state attribute and the
adapter recovery can be performed manually by walking all fc_rports
writing their port_state.)

I don't think the sdev 'state' attribute is useable here; it doesn't trigger a rediscovery. You'd want to use 'rescan' here.
But yeah, that would be one of the goals.

Still waiting for some response to the patch, though.
Testing has been successful on our side, plus I've posted
a patchset for multipath-tools utilizing this patch.

So it would be good if it could be included.

James?

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

Reply via email to