Messages in this thread | | | Date | Sun, 15 Sep 2002 23:12:22 +0200 | From | Lars Marowsky-Bree <> | Subject | Re: Possible Bug with MD multipath and raid1 on top |
| |
On 2002-09-15T07:29:30, Oktay Akbal <oktay.akbal@s-tec.de> said:
> > Is this with or without the patch I recently posted to linux-kernel? > > Since it is the latest official Suse-2.4.18 from SLES I assume this patch > is not included.
Oh, ok. Multipathing is known to not work perfectly right in the mainstream kernel. In this case, you might want to try the patch.
> > So far this sounds OK. > All disks are dead. The md0 device is missing. The same should be true for > md1, since there is no difference in setup. Why should the raid1 no report > both mirrors as dead ?
Oh, right. I misread your mail and just saw that the md1 was also on the same devices. Strange indeed.
> > (Even though the updated md-mp patch will _never_ fail the last path but > > instead return the error to the layer upwards; this protects against > > certain scenarios in 2.4 where a device error can't be distinguished from > > a failed path and we don't want that to lead to an inaccessible device) > How would the failing of all Pathes then be noticed ?
Well, IO errors would occur, be reported to the caller and those would supposedly be noticed.
However, the 2.4 error reporting can't distinguish between a path or a device error. So a failed read (destroyed block, for example) will fail a path. As the read request is retried on all paths if necessary, it would be highly undesireable to fail _all_ paths because of this. The last path will remain "accessible", but the application will see an error in this case.
> This might well be, since I don't found the qlogic-driver very impressing > so far. To use md-multipath the multipathing (failover) functionality from > the driver was disabled.
OK. Well, I never tested the QLogic proprietary failover because I consider it to be the wrong approach ;-) The md layer should work though by now.
Sincerely, Lars Marowsky-Brée <lmb@suse.de>
-- Immortality is an adequate definition of high availability for me. --- Gregory F. Pfister
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |