We weren't aware of it. We'll look further... -- james > -----Original Message----- > From: christophe.varoqui@xxxxxxx [mailto:christophe.varoqui@xxxxxxx] > Sent: Friday, December 10, 2004 4:23 AM > To: Smart, James > Cc: dm-devel@xxxxxxxxxx > 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@xxxxxxxxxx: > > > 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 > > > > > > > -- > > > > dm-devel@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/dm-devel > > > > > -- >