On 17 Apr 2009 at 15:22, dave wrote: > > Long post, but please bear with me :) > > This post is related to my previous post at: > http://groups.google.com/group/open-iscsi/browse_thread/thread/4569bc674383145a/e6c2e4320ec401f5?lnk=gst&q=device+not+ready#e6c2e4320ec401f5 > > My situation: > > I have linux initiators running open-iscsi 2.0-869 with dm-multipath, > queue_if_no_path enabled. The target is an OpenSolaris box sharing > zvols from a mirrored zpool, which means the target LUNs are virtual > devices with storage backed by the ZFS zpool. > > The problem: > > When one of the disks in the solaris zpool dies, ZFS halts reads/ > writes to the zpool for a minute or two while it waits for the disk > controller/driver to determine if the device should be offlined. The > side effect of this is that because the iSCSI targets are virtual > devices with their data store being the ZFS zpool, the iSCSI read/ > writes are also halted as long as ZFS is waiting for a device to fail. > The iSCSI targets don't disappear, they are just unable to complete > read/write ops - they still respond fine to logins and target > discovery. Once ZFS continues operation, the iSCSI devices also resume > normal operation. Since I am using multipath on the linux initiators, > the linux boxes can wait patiently for read/writes to resume, but it > seems that the scsi system does not retry TUR messages which can cause > the device to never be put back into operation on the initiator node.
Hi! I guess the TUR are queued, just as any other SCSI command. Thus the TURs will be processed after your virtual LUNs did recover. This brings up an issue I was thinking about already: Does it make any sense for mutipath to run a path checker, wehen there was regular traffic (command/response) recently? Likewise, (I don't know if iopen-iscsi does that) does it make sense to send No-Ops to a target if the target had sent a reply recently? I'm seeing quite busy switch ports, een if the iSCSI data traffic is expected to be very low. With 16 paths per LUN here, frequent probing by multipath and open- iscsi would be one explanation. [...] Regards, Ulrich --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@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 -~----------~----~----~----~------~----~------~--~---
