On Thu, Sep 02, 2010 at 03:15:31PM -0700, Shantanu Mehendale wrote: > Hi Hannes/Mike, > > I am also dealing with another issue on ISCSI transport where I am > seeing "DID_TRASNPORT_FAILFAST" hostbyte errors reaching the application > which is sending I/O on a device-mapper node. Reading the code a little > I thought that after the iscsi replacement_timeout timer fires, the io > stuck in the io queues will be sent up to the device-mapper, which > would send the io to the new path. Is there a possibility that > dm-multipath is not able to handle all the errors so some of them end > up going to the application. Basically this is a cable pull kind of > experiment where we would expect the path failover to work and io to > continue properly. Yes, in general it should. And yes, multipath should handle these cases. But I did quite some patches to iSCSI in SLES11, so you should be making sure you're using the latest maintenance release.
> Since we already saw one problem with "DID_TRANSPORT_DISRUPTED", I was > wondering if "DID_TRANSPORT_FAILFAST" also has some similar issues with > limited retries and such. > No, that's actually okay. The I/O error will be reported in either case, it's just that it'll never reaches the upper layers. In your case it looks as if the 'tapdisk' thing runs on the raw disks, not the multipathed device. So of course it'll register the error. Maybe it's an idea to have the 'tapdisk' run on the multipath device-mapper device ... Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- 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.
