linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oktay Akbal <oktay.akbal@s-tec.de>
To: linux-kernel@vger.kernel.org
Subject: Possible Bug with MD multipath and raid1 on top
Date: Sat, 14 Sep 2002 20:33:07 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.44.0209142014080.21833-100000@omega.s-tec.de> (raw)

Hello,

I found a very strange effect when using a raid1 on top of multipathing
with Kernel 2.4.18 (Suse-version of it) with a 2-Port qlogic HBA
connecting two arrays.

The raidtab used to set this up is:

raiddev                 /dev/md0
raid-level              multipath
nr-raid-disks           1
nr-spare-disks          1
chunk-size              32

device                  /dev/sda1
raid-disk               0

device                  /dev/sdc1
spare-disk              1

raiddev                 /dev/md1
raid-level              multipath
nr-raid-disks           1
nr-spare-disks          1
chunk-size              32

device                  /dev/sdb1
raid-disk               0

device                  /dev/sdd1
spare-disk              1

raiddev                 /dev/md2
raid-level              1
nr-raid-disks           2
nr-spare-disks          0
chunk-size              32

device                  /dev/md0
raid-disk               0

device                  /dev/md1
raid-disk               1


As you see, one port from the hba "sees" sda and sdb, the second port
sdc and sdd.
When I now pull out one of the cables two disks are missing and the
multipath driver correctly uses the second path to the disks and
continues to work. After plugging out the second cable all drives
are marked as failed (mdstat), but the raid1 (md2) is still reported
as functional with one device (md0) missing.
(Sorry do not have the output at hand but md2 was reported [_U], while
sda-sdd were marked [F]).

All Processes using the raid1-device get stuck and this situation
does not recover. Even some simple process testing the disk-access
got stuck  (I think ps showed state   L<D).

Even if I'm quite sure that this is a bug, how should I test disk access
without ending in "uninterruptible sleep" ?

Thanks

Oktay Akbal


             reply	other threads:[~2002-09-14 18:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-14 18:33 Oktay Akbal [this message]
2002-09-14 23:07 ` Possible Bug with MD multipath and raid1 on top Lars Marowsky-Bree
2002-09-15  5:29   ` Oktay Akbal
2002-09-15 21:12     ` Lars Marowsky-Bree
2002-09-15  7:31   ` Nachtrag: " Oktay Akbal
2002-09-15  7:39     ` Oktay Akbal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0209142014080.21833-100000@omega.s-tec.de \
    --to=oktay.akbal@s-tec.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).