On Tue, Jun 20, 2006 at 02:45:23PM -0400, James Smart wrote: > Folks, > > The following addresses some long standing todo items I've had in the > FC transport. They primarily arise when considering multipathing, or > trying to marry driver internal state to transport state. It is intended > that this same type of functionality would be usable in other transports > as well. > > Here's what is contained: > > - dev_loss_tmo LLDD callback : > Currently, there is no notification to the LLDD of when the transport > gives up on the device returning and starts to return DID_NO_CONNECT > in the queuecommand helper function. This callback notifies the LLDD > that the transport has now given up on the rport, thereby acknowledging > the prior fc_remote_port_delete() call. The callback also expects the > LLDD to initiate the termination of any outstanding i/o on the rport. I think this is fine. > - fast_io_fail_tmo and LLD callback: > There are some cases where it may take a long while to truly determine > device loss, but the system is in a multipathing configuration that if > the i/o was failed quickly (faster than dev_loss_tmo), it could be > redirected to a different path and completed sooner (assuming the > multipath thing knew that the sdev was blocked). shouldn't we just always fail REQ_FAILFAST requests ASAP and totally ignore any kind of devloss timeout for them? > This attribute is an exported "recommendation" by the LLDD and transport > on what the lowest setting for dev_loss_tmo should be for a multipathing > environment. Thus, the admin only needs to cat this attribute to obtain > the value to echo into dev_loss_tmo. This kind of policy really doesn't belong into the kernel. I'd rather see a nice userspace command to get this right for the user as part of sg_utils or Jeffs infamous blktool. > I have one criticism of these changes. The callbacks are calling into > the LLDD with an rport post the driver's rport_delete call. What it means > is that we are essentially extending the lifetime of an rport until the > dev_loss_tmo call occurs. Which is okay as long as it's documented well enough. - : 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
