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",
+                                session->dev_loss_tmo);

3) As FC hardly ever looses packets or suffers from variable delays, it's much 
easier to timeout an FC device than a TCP device (IMHO)

4)  With Linux an non-persistent device names, frequent remove and re-add of 
devices should be avoided if possible (In other operating systems the same 
device file may re-appear if the device comes back online)

5) I hope (i.e. I have no idea about it) that outstanding requests for a device 
that is going to be removed are removed cleanly before as well.

Regards,
Ulrich


>>> Mike Christie <micha...@cs.wisc.edu> schrieb am 06.10.2010 um 10:46 in
Nachricht <4cac376c.3040...@cs.wisc.edu>:
> 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 
> (actually multipathd and dm-multipath work together) then handle hotplug 
> removal events from the device deletion event, by removing paths from 
> the dm-multipath device.
> 
> When the session gets logged back in, we kick off a scan and re-find 
> devices. multipathd and dm-multipath then handle this by adding the 
> paths back to the multipath device.
> 
> If you are not using dm-multipath and are mounting the FS on the iscsi 
> device then you basically see the same thing as before. IO errors, 
> followed by the FS getting mounted read only.
> 
> This patch will also fix a problem where if a device is offlined due to 
> the transport going kaput scsi_internal_device_unblock() would not set 
> the device back to running. With this patch the device gets destroyed 
> and a new one gets added, so we completely bypass that problem like how 
> FC and SAS does (note: it does not address the problem with 
> iscsi_block_eh races - waiting on the fc discussion).
> 
> This patch was made over Linus's tree but can be applied to scsi-misc or 
> scsi-rc-fixes. I have only done some light testing. I wanted to post 
> this though, so other driver developers could test it out.



 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Reply via email to