[dm-devel] Multipath and HSG80 phase 2

[James.Smart at Emulex.Com]

We weren't aware of it. We'll look further...

-- james

> -----Original Message-----
> From: christophe.varoqui at free.fr [mailto:christophe.varoqui at free.fr]
> Sent: Friday, December 10, 2004 4:23 AM
> To: Smart, James
> Cc: dm-devel at redhat.com
> Subject: RE: [dm-devel] Multipath and HSG80 phase 2
> 
> 
> Have you noticed the lpfc module refcounting looks shaky ?
> 
> xa-s05:~# lsmod
> Module                  Size  Used by
> dm_round_robin          5248  1
> af_packet              25228  2
> iscsi_sfnet           124956  0
> ipv6                  273376  22
> smbfs                  72328  3
> lpfc                  159968  946
> scsi_transport_fc      10368  1 lpfc
> ...
> 
> regards,
> cvaroqui
> 
> Selon 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
> > >
> >
> > --
> > dm-devel mailing list
> > dm-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/dm-devel
> >
> 
> 
> --
>