Home » Blogs » mike's blog

Failing paths with tur multipath path checker

Submitted by mike on Thu, 2006-04-27 17:14

After seeing a growing number of errors about failing paths on all our mutipath machines (Hitachi DF-600 over QLogic 2340 HBAs), we switched the multipath path checker from tur to readsector0 in /etc/multipath.conf and syslog went silent again.

Apr 13 08:19:04 hostname multipathd: 8:144: tur checker reports path is down
Apr 13 08:19:04 hostname multipathd: checker failed path 8:144 in map lu_u00
Apr 13 08:19:04 hostname kernel: device-mapper: dm-multipath: Failing path 8:144
Apr 13 08:19:15 hostname multipathd: 8:144: tur checker reports path is up
Apr 13 08:19:15 hostname multipathd: 8:144: reinstated

Update 2006-05-04
After some time, the errors were back. We have now changed the path checker to directio. Additionally, I have set all qla2xxx module parameters back to their defaults. Let's see how far we get with this.

We were seeing the same

Submitted by Scott Smyth (not verified) on Wed, 2006-09-06 23:52.

We were seeing the same things with dm-multipath as described. We use linux kernel v2.6.15 with
some of our own (and other's) patches with device-mapper v1.02.03, multipath-tools v0.4.7,
and udev v039.

Our issue centered around trying to start /sbin/multipathd ahead of vgscan/vgchange so we would not
get the warnings about identical devices from vgscan when physically being connected to two
QLogic FC controllers inside the same system. However, when we did this, and then started
udevd after /sbin/multipathd, we had the same problems with multipath-tools as described here
and failed paths that are seen above. Our hardware is: QLogic FC 2300/2xxx drivers,
Xyratex FC-to-SATA RAID set systems, and linux NAS head (dual Opterons, linux 2.6.15).

Then, we switched back to starting /sbin/multipathd in its own initscript and out of rc.sysinit. We just
lived with the identical device errors from the first call of vgscan. At this change, the problems with low-level
sector errors and path errors stopped with all our tests. If you are starting multipathd before udevd,
you might want to switch these and see what happens. So far, so good for our start daemon order.