From: NeilBrown <neilb@suse.de>
To: "David F." <df7729@gmail.com>
Cc: Martin Wilck <mwilck@arcor.de>,
"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: MDADM 3.3 broken?
Date: Mon, 20 Jan 2014 15:34:21 +1100 [thread overview]
Message-ID: <20140120153421.456f864f@notabene.brown> (raw)
In-Reply-To: <CAGRSmLugnbB=_xTOPYnzTBvrOPZoHi8oSzs53-_cdBgttb7VXg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3908 bytes --]
On Sat, 14 Dec 2013 13:01:50 -0800 "David F." <df7729@gmail.com> wrote:
> Hi,
>
> Just wondering if this gave you guys everything you needed to figure
> out the issue?
I had everything but time. I've now made the time and have the fix (I hope).
Please try the current HEAD of git://neil.brown.name/mdadm/
The important patch is below.
>
> Also, any idea on when 3.4 may be out with the various fixes?
I hope to release 3.3.1 some time in February. Based on past experience it
should be out before Easter, but no promises.
NeilBrown
From f0e876ce03a63f150bb87b2734c139bc8bb285b2 Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb@suse.de>
Date: Mon, 20 Jan 2014 15:27:29 +1100
Subject: [PATCH] DDF: fix detection of failed devices during assembly.
When we call "getinfo_super", we report the working/failed status
of the particular device, and also (via the 'map') the working/failed
status of every other device that this metadata is aware of.
It is important that the way we calculate "working or failed" is
consistent.
As it is, getinfo_super_ddf() will report a spare as "working", but
every other device will see it as "failed", which leads to failure to
assemble arrays with spares.
For getinfo_super_ddf (i.e. for the container), a device is assumed
"working" unless flagged as DDF_Failed.
For getinfo_super_ddf_bvd (for a member array), a device is assumed
"failed" unless DDF_Online is set, and DDF_Failed is not set.
Reported-by: "David F." <df7729@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
diff --git a/super-ddf.c b/super-ddf.c
index d526d8ad3da9..4242af86fea9 100644
--- a/super-ddf.c
+++ b/super-ddf.c
@@ -1913,6 +1913,7 @@ static void getinfo_super_ddf(struct supertype *st, struct mdinfo *info, char *m
info->disk.major = 0;
info->disk.minor = 0;
if (ddf->dlist) {
+ struct phys_disk_entry *pde = NULL;
info->disk.number = be32_to_cpu(ddf->dlist->disk.refnum);
info->disk.raid_disk = find_phys(ddf, ddf->dlist->disk.refnum);
@@ -1920,12 +1921,19 @@ static void getinfo_super_ddf(struct supertype *st, struct mdinfo *info, char *m
entries[info->disk.raid_disk].
config_size);
info->component_size = ddf->dlist->size - info->data_offset;
+ if (info->disk.raid_disk >= 0)
+ pde = ddf->phys->entries + info->disk.raid_disk;
+ if (pde &&
+ !(be16_to_cpu(pde->state) & DDF_Failed))
+ info->disk.state = (1 << MD_DISK_SYNC) | (1 << MD_DISK_ACTIVE);
+ else
+ info->disk.state = 1 << MD_DISK_FAULTY;
} else {
info->disk.number = -1;
info->disk.raid_disk = -1;
// info->disk.raid_disk = find refnum in the table and use index;
+ info->disk.state = (1 << MD_DISK_SYNC) | (1 << MD_DISK_ACTIVE);
}
- info->disk.state = (1 << MD_DISK_SYNC) | (1 << MD_DISK_ACTIVE);
info->recovery_start = MaxSector;
info->reshape_active = 0;
@@ -1943,8 +1951,6 @@ static void getinfo_super_ddf(struct supertype *st, struct mdinfo *info, char *m
int i;
for (i = 0 ; i < map_disks; i++) {
if (i < info->array.raid_disks &&
- (be16_to_cpu(ddf->phys->entries[i].state)
- & DDF_Online) &&
!(be16_to_cpu(ddf->phys->entries[i].state)
& DDF_Failed))
map[i] = 1;
@@ -2017,7 +2023,11 @@ static void getinfo_super_ddf_bvd(struct supertype *st, struct mdinfo *info, cha
info->disk.raid_disk = cd + conf->sec_elmnt_seq
* be16_to_cpu(conf->prim_elmnt_count);
info->disk.number = dl->pdnum;
- info->disk.state = (1<<MD_DISK_SYNC)|(1<<MD_DISK_ACTIVE);
+ info->disk.state = 0;
+ if (info->disk.number >= 0 &&
+ (be16_to_cpu(ddf->phys->entries[info->disk.number].state) & DDF_Online) &&
+ !(be16_to_cpu(ddf->phys->entries[info->disk.number].state) & DDF_Failed))
+ info->disk.state = (1<<MD_DISK_SYNC)|(1<<MD_DISK_ACTIVE);
}
info->container_member = ddf->currentconf->vcnum;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2014-01-20 4:34 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-18 18:26 MDADM 3.3 broken? David F.
2013-11-18 20:22 ` Martin Wilck
2013-11-18 23:13 ` David F.
2013-11-19 0:01 ` NeilBrown
2013-11-19 17:05 ` David F.
2013-11-19 20:38 ` Martin Wilck
2013-11-19 22:34 ` David F.
2013-11-19 22:49 ` David F.
2013-11-19 19:45 ` Martin Wilck
2013-11-19 20:08 ` David F.
2013-11-19 23:51 ` NeilBrown
2013-11-20 0:22 ` David F.
2013-11-20 0:35 ` David F.
2013-11-20 0:48 ` NeilBrown
2013-11-20 1:29 ` David F.
2013-11-20 1:34 ` David F.
2013-11-20 2:30 ` NeilBrown
2013-11-20 6:41 ` David F.
2013-11-20 23:15 ` David F.
2013-11-21 20:50 ` Martin Wilck
2013-11-21 21:10 ` David F.
2013-11-21 21:30 ` Martin Wilck
2013-11-21 22:39 ` David F.
2013-11-25 21:39 ` Martin Wilck
2013-11-21 20:46 ` Martin Wilck
2013-11-21 21:06 ` David F.
2013-11-21 23:05 ` David F.
2013-11-21 23:09 ` David F.
2013-11-22 3:06 ` David F.
2013-11-22 18:36 ` David F.
2013-11-23 23:36 ` David F.
2013-11-25 21:56 ` Martin Wilck
2013-11-26 0:24 ` David F.
2013-11-26 21:59 ` David F.
2013-11-27 22:40 ` Martin Wilck
2013-12-06 1:53 ` David F.
2013-12-07 2:28 ` David F.
2013-12-07 3:16 ` NeilBrown
2013-12-07 3:46 ` David F.
2013-12-14 21:01 ` David F.
2014-01-20 4:34 ` NeilBrown [this message]
2014-01-20 21:52 ` Martin Wilck
2014-01-20 23:54 ` David F.
2014-01-22 22:32 ` David F.
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=20140120153421.456f864f@notabene.brown \
--to=neilb@suse.de \
--cc=df7729@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=mwilck@arcor.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.