On Tue, Mar 09, 2010 at 09:14:37AM -0500, James Smart wrote: > I don't ever expect to see large dev_loss_tmo values, but the patch is fine. > > Acked-by: James Smart <james.smart@xxxxxxxxxx> > > -- james s > > > Hannes Reinecke wrote: > >The rport structure defines dev_loss_tmo as u32, which is > >later multiplied with HZ to get the actual timeout value. > >This might overflow for large dev_loss_tmo values. So we > >should be better using u64 as intermediate variables here > >to protect against overflow. > > > >Signed-off-by: Hannes Reinecke <hare@xxxxxxx> [...] I guess this is the intended use to prevent the dev_loss_tmo from removing the SCSI devices: http://git.kernel.org/?p=linux/kernel/git/hare/multipath-tools.git;a=commitdiff;h=b9903e2e8a6cdc5042897719fbae6c9346820bbf;hp=ed1dc6164fe530d146cfe65d4f99e44ec9b54b95 But does this raise the question again how to run SCSI EH with remote port failures? The SCSI FC LLDs call fc_block_scsi_eh to wait until the fc_rport leaves the state FC_PORTSTATE_BLOCKED. This effectively prevents SCSI devices from being taken offline when there is a command timeout and the fc_rport is BLOCKED. With the large dev_loss_tmo, the dev_loss_tmo never expires and a problem with a single remote port can block the host error handler. -- Christof -- 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
