<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: SV: [linux-cluster] multipath issue... Smells of hardware issue.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>RR<BR>
<BR>
Sent from my GoodLink synchronized handheld (www.good.com)<BR>
<BR>
<BR>
 -----Original Message-----<BR>
From:   SUVANKAR MOITRA [<A HREF="mailto:suvankar_moitra@yahoo.com">mailto:suvankar_moitra@yahoo.com</A>]<BR>
Sent:   Friday, July 06, 2007 03:33 AM Pacific Standard Time<BR>
To:     linux clustering<BR>
Subject:        Re: SV: [linux-cluster] multipath issue... Smells of hardware issue.<BR>
<BR>
hi ,<BR>
<BR>
Pl install the device driver in failover mode.<BR>
<BR>
regards<BR>
<BR>
Suvankar<BR>
--- Kristoffer Lippert <kristoffer.lippert@jppol.dk><BR>
wrote:<BR>
<BR>
> Hi,<BR>
><BR>
> Thank you very  much for the explaination.<BR>
><BR>
> The hardware should under no circumstances take 5<BR>
> minutes to perform a readsector. Not even when the<BR>
> command queue is very long.<BR>
> I've tried copying files to and from the SAN, and<BR>
> i've tried a little program called sys_basher<BR>
> working the disks continously since last Friday.<BR>
> (almost a week) and i have not been able to<BR>
> reproduce the error. Before i could produce it<BR>
> within an hour by copying files.<BR>
> I've only seen the error on one server, and i've<BR>
> changed nothing. (well, obvouisly something must<BR>
> have changed since the error seems to be gone.)<BR>
><BR>
> I get a throughput of about 120mb/sec on the san<BR>
> using GFS1. It's fast enough for my use (wich is<BR>
> large files for a website). Is it far below expected<BR>
> throughput?<BR>
><BR>
> Kind regards<BR>
> Kristoffer<BR>
><BR>
><BR>
><BR>
><BR>
> -----Oprindelig meddelelse-----<BR>
> Fra: linux-cluster-bounces@redhat.com<BR>
> [<A HREF="mailto:linux-cluster-bounces@redhat.com">mailto:linux-cluster-bounces@redhat.com</A>] På vegne<BR>
> af Benjamin Marzinski<BR>
> Sendt: 5. juli 2007 22:01<BR>
> Til: linux clustering<BR>
> Emne: Re: [linux-cluster] multipath issue... Smells<BR>
> of hardware issue.<BR>
><BR>
> On Fri, Jun 29, 2007 at 05:23:20PM +0200, Kristoffer<BR>
> Lippert wrote:<BR>
> >    Hi,<BR>
> ><BR>
> >    I have a setup with two identical RX200s3 FuSi<BR>
> servers talking to a SAN<BR>
> >    (SX60 + extra controller), and that works fine<BR>
> with gfs1.<BR>
> ><BR>
> >    I do however see some errors on one of the<BR>
> servers. It's in my message log<BR>
> >    and only now and then now and then (though<BR>
> always under load, but i cant<BR>
> >    load it and thereby force it to give the<BR>
> error).<BR>
> ><BR>
> >    The error says:<BR>
> >    Jun 28 15:44:17 app02 multipathd: 8:16: mark as<BR>
> failed<BR>
> >    Jun 28 15:44:17 app02 multipathd:<BR>
> main_disk_volume1: remaining active<BR>
> >    paths: 1<BR>
> >    Jun 28 15:44:17 app02 kernel: sd 2:0:0:0: SCSI<BR>
> error: return code =<BR>
> >    0x00070000<BR>
> >    Jun 28 15:44:17 app02 kernel: end_request: I/O<BR>
> error, dev sdb, sector<BR>
> >    705160231<BR>
> >    Jun 28 15:44:17 app02 kernel: device-mapper:<BR>
> multipath: Failing path 8:16.<BR>
> >    Jun 28 15:44:22 app02 multipathd: sdb:<BR>
> readsector0 checker reports path is<BR>
> >    up<BR>
> >    Jun 28 15:44:22 app02 multipathd: 8:16:<BR>
> reinstated<BR>
> >    Jun 28 15:44:22 app02 multipathd:<BR>
> main_disk_volume1: remaining active<BR>
> >    paths: 2<BR>
> >    Jun 28 15:46:02 app02 multipathd: 8:32: mark as<BR>
> failed<BR>
> >    Jun 28 15:46:02 app02 multipathd:<BR>
> main_disk_volume1: remaining active<BR>
> >    paths: 1<BR>
> >    Jun 28 15:46:02 app02 kernel: sd 3:0:0:0: SCSI<BR>
> error: return code =<BR>
> >    0x00070000<BR>
> >    Jun 28 15:46:02 app02 kernel: end_request: I/O<BR>
> error, dev sdc, sector<BR>
> >    739870727<BR>
> >    Jun 28 15:46:02 app02 kernel: device-mapper:<BR>
> multipath: Failing path 8:32.<BR>
> >    Jun 28 15:46:06 app02 multipathd: sdc:<BR>
> readsector0 checker reports path is<BR>
> >    up<BR>
> >    Jun 28 15:46:06 app02 multipathd: 8:32:<BR>
> reinstated<BR>
> >    Jun 28 15:46:06 app02 multipathd:<BR>
> main_disk_volume1: remaining active<BR>
> >    paths: 2<BR>
> ><BR>
> >    To me i looks like a fiber that bounces up and<BR>
> down. (There is no switch<BR>
> >    involved).<BR>
> ><BR>
> >    Sometimes i only get a slightly shorter<BR>
> version:<BR>
> >    Jun 29 09:04:32 app02 kernel: sd 2:0:0:0: SCSI<BR>
> error: return code =<BR>
> >    0x00070000<BR>
> >    Jun 29 09:04:32 app02 kernel: end_request: I/O<BR>
> error, dev sdb, sector<BR>
> >    2782490295<BR>
> >    Jun 29 09:04:32 app02 kernel: device-mapper:<BR>
> multipath: Failing path 8:16.<BR>
> >    Jun 29 09:04:32 app02 multipathd: 8:16: mark as<BR>
> failed<BR>
> >    Jun 29 09:04:32 app02 multipathd:<BR>
> main_disk_volume1: remaining active<BR>
> >    paths: 1<BR>
> >    Jun 29 09:04:37 app02 multipathd: sdb:<BR>
> readsector0 checker reports path is<BR>
> >    up<BR>
> >    Jun 29 09:04:37 app02 multipathd: 8:16:<BR>
> reinstated<BR>
> >    Jun 29 09:04:37 app02 multipathd:<BR>
> main_disk_volume1: remaining active<BR>
> >    paths: 2<BR>
> ><BR>
> >    Any sugestions, but start swapping hardware?<BR>
><BR>
> It's possible that your scsi device is timing out<BR>
> the scsi read command from the readsector0 path<BR>
> checker, which is what it appears that your setup is<BR>
> using to check the path status.  This checker has<BR>
> it's timeout set to 5 minutes, but I suppose that it<BR>
> is possible to take this long if your hardware is a<BR>
> flaky. If you're willing to recompile the code, you<BR>
> can change this default by changing DEF_TIMEOUT in<BR>
> libcheckers/checkers.h. DEF_TIMEOUT is the scsi<BR>
> command timeout in milliseconds.<BR>
><BR>
> Otherwise, if you are only seeing this on one<BR>
> server, swapping hardware seems like a reasonable<BR>
> thing to try.<BR>
><BR>
> -Ben<BR>
> <BR>
> >    Mvh / Kind regards<BR>
> ><BR>
> >    Kristoffer Lippert<BR>
> >    Systemansvarlig<BR>
> >    JP/Politiken A/S<BR>
> >    Online Magasiner<BR>
> ><BR>
> >    Tlf. +45 8738 3032<BR>
> >    Cell. +45 6062 8703<BR>
><BR>
> > --<BR>
> > Linux-cluster mailing list<BR>
> > Linux-cluster@redhat.com<BR>
> ><BR>
><BR>
<A HREF="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</A><BR>
><BR>
> --<BR>
> Linux-cluster mailing list<BR>
> Linux-cluster@redhat.com<BR>
><BR>
<A HREF="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</A><BR>
><BR>
> --<BR>
> Linux-cluster mailing list<BR>
> Linux-cluster@redhat.com<BR>
><BR>
<A HREF="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</A><BR>
><BR>
<BR>
<BR>
<BR>
      ____________________________________________________________________________________<BR>
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.<BR>
<A HREF="http://autos.yahoo.com/green_center/">http://autos.yahoo.com/green_center/</A><BR>
<BR>
--<BR>
Linux-cluster mailing list<BR>
Linux-cluster@redhat.com<BR>
<A HREF="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</A><BR>
</FONT>
</P>

</BODY>
</HTML>