Michael Reed wrote:
Haven't most drivers / board firmware generally cleaned up any outstanding i/o at the time (or shortly thereafter) of the fc_remote_port_delete() call? I would think it reasonable to just require that the driver clean up the i/o after calling fc_remote_port_delete(). Is there a significant reason to keep the i/o alive in the driver? The rport has just been deleted.... Would this eliminate the need for the callback? If the driver implements this, could it just have a NULL callback routine?
You don't want to kill i/o at the time that the rport loses connectivity (e.g. when we call delete). The biggest reason is for devices that support FCP Recovery (Tape being a prime example, but it's not limited to them). There are also several topology glitches, which can be seconds in length, which are abberant, and really didn't reflect true device loss. Why kill and reissue these io's as well ? it really just adds more load to the system to abort and retry the i/o's. Also, FC-DA compliance is recommending that the login and the exchanges stay around as long as possible (you could argue the diagram mandates it). So, for the best "FC behavior" you really shouldn't kill the i/o until dev_loss_tmo fires. -- james s PS: I think you're highlighting my complaint with the patch. I should be renaming the "delete" function as it really isn't delete. The rport isn't truly "deleted" until dev_loss_tmo fires. We didn't consider this when we dropped the block/unblock_rport routines in favor of the more straight-forward add/delete calls. At this point, I'd rather document the lifetime in the api/header than deal with namechanges and its affects on drivers/distros. - : 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
