Christoph, I can think of at least 1 reasonable reason why you have "long" delays with the Emulex driver. It attempts to hide temporary device loss for normal operation. Thus, there's a timer that waits before we start erroring i/o. For multipathing - you want this timer as low as zero. If you're running the 8.x driver , try setting the module parameter lpfc_nodev_tmo=0. Also, older driver revs had issues with "cable pulls", which are the port removal tests. In order to get decent behavior, we required a kernel patch (in 2.6.10-rc's), a minimum driver rev of 8.0.14 (but I'd run the latest anyway - it's 8.0.16), and compilation by "make BUILD_FC_TRANS=1" (see the RELEASE-NOTES file). Sorry this isn't plug-n-play yet. It will be as we complete the upstream process. -- James S > -----Original Message----- > From: dm-devel-bounces@xxxxxxxxxx > [mailto:dm-devel-bounces@xxxxxxxxxx]On > Behalf Of christophe.varoqui@xxxxxxx > Sent: Thursday, December 09, 2004 11:38 AM > To: device-mapper development > Subject: Re: [dm-devel] Multipath and HSG80 phase 2 > > > > > I have already sent Christophe a patch for this. The > problem was he set p, > > moved p, realloced dst, and expected dst to start at the same memory > > locating it was at before reallocing, which may or may not > be true. The fix > > moves the p assignment and movement after the realloc call. > > > Indeed, > can you audit your fixes in > http://christophe.varoqui.free.fr/multipath-tools/multipath-to > ols-0.4.0.tar.bz2 > before I release it ? > > ... and report on general behaviour. > > I'm also interested in knowing how your servers behave when > you disable ports > during IO. The device mapper seems fragile here on > StorageWorks HW and Emulex > HBA. > > Precisely, I experience a looong delay with all IO blocked, > then an oops, then > IO restart on remaining paths. But then re-enabling port > doesn't make the > device mapper happy and I have to remove-add-cycle the path > at the SCSI layer > for the DM to accept it again in maps. > > regards, > cvaroqui > -- > > -- > > dm-devel@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/dm-devel >