Mike Christie wrote:
Hey,
At storage summit this year, it was decided iscsi needs to catch up with
the other iscsi drivers, and add something like FC's dev_loss_tmo. When
this timeout expires, it will cause the iscsi layer to remove the scsi
devices and fail any IO that was queued. Upper
On 10/07/2010 02:02 AM, Hannes Reinecke wrote:
Mike Christie wrote:
Hey,
At storage summit this year, it was decided iscsi needs to catch up with
the other iscsi drivers, and add something like FC's dev_loss_tmo. When
this timeout expires, it will cause the iscsi layer to remove the scsi
Hey,
At storage summit this year, it was decided iscsi needs to catch up with
the other iscsi drivers, and add something like FC's dev_loss_tmo. When
this timeout expires, it will cause the iscsi layer to remove the scsi
devices and fail any IO that was queued. Upper layers like dm-multipath
Some random comments:
1) What will be the default value for the new timeout?
2) I think this should be at least KERN_WARN(ing):
+ iscsi_cls_session_printk(KERN_INFO, session,
+session dev loss timed out after %d secs\n,
+
On 10/06/2010 04:54 AM, Ulrich Windl wrote:
Some random comments:
1) What will be the default value for the new timeout?
Not, sure yet. Suggestions?
2) I think this should be at least KERN_WARN(ing):
+ iscsi_cls_session_printk(KERN_INFO, session,
+