[dm-devel] Multipath and HSG80 phase 2

[James.Smart at Emulex.Com]

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 at redhat.com 
> [mailto:dm-devel-bounces at redhat.com]On
> Behalf Of christophe.varoqui at free.fr
> 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 mailing list
> dm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>