From: NeilBrown <neilb@suse.de>
To: Kenneth Emerson <kenneth.emerson@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: md metadata nightmare
Date: Wed, 23 Nov 2011 11:47:43 +1100 [thread overview]
Message-ID: <20111123114743.1085889e@notabene.brown> (raw)
In-Reply-To: <CADzwnhXWvkVC13ZEJj8L0O6PLXLS6uhoBXqoLp67YwmeU60sQQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]
On Tue, 22 Nov 2011 18:05:21 -0600 Kenneth Emerson
<kenneth.emerson@gmail.com> wrote:
> NOTE: I have set the linux-raid flag on all of the partitions in the
> GPT. I think I have read in the linux-raid archives that this is not
> recommended. Could this have had an affect on what transpired?
Net recommended, but also totally ineffective. The Linux-RAID partition type
is only recognised in MS-DOS partition tables.
>
> So my question is:
>
> Is there a way, short of backing up the data, completely rebuilding
> the arrays, and restoring the data (a real PIA) to rewrite the
> metadata given the existing array configurations in the running
> system? Also, is there an explanation as to why the metadata seems so
> screwed up that the arrays cannot be assembled automatically by the
> kernel?
There appear to be two problems here. Both could be resolved by converting to
v1.0 metadata. But there are other approaches. And converting to v1.0 is
not trivial (not enough developers to work on all the tasks!).
One problem is the final partition on at least some of your disks is at a 64K
alignment. This means that the superblock looks valid for both the whole
device and for the partition.
You can confirm this by running
mdadm --examine /dev/sda
mdadm --examine /dev/sda4
(ditto for b,c,d,e,...)
The "sdX4" should show a superblock. The 'sdX' should not.
I think it will show exactly the same superblock. It could show a different
superblock... that would be interesting.
If I am correct here then you can "fix" this by changing mdadm.conf to read:
DEVICES /dev/sda? /dev/sdb? /dev/sdc? /dev/sdd? /dev/sde?
or
DEVICES /dev/sd[abcde][1-4]
or similar. i.e. tell it to ignore the whole devices.
The other problem is that v0.90 metadata isn't good with very large devices.
It has 32bits to record kilobytes per device.
This show allow 4TB per device but due to a bug (relating to sign bits) it
only works well with 2TB per device. This bug was introduced in 2.6.29 and
removed in 3.1.
So if you can run a 3.1.2 kernel, that would be best.
You could convert to v1.0 if you want. You only need to do this for the last
partition (sdX4).
Assuming nothing has changed since the "--detail" output you provided, you
should:
mdadm -S /dev/md3
mdadm -C /dev/md3 --metadata=1.0 --chunk=64k --level=6 --raid-devices=5 \
missing /dev/sdb4 /dev/sdc4 /dev/sda4 /dev/sdd4 \
--assume-clean
The order of the disks is import. You should compare it with the output
of "mdadm --detail" before you start to ensure that it is correct and I have
made any typos. You should of course check the rest as well.
After doing this (and possibly before) you should 'fsck' to ensure the
transition was successful. If anything goes wrong, ask before risking
further breakage.
Good luck.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2011-11-23 0:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-23 0:05 md metadata nightmare Kenneth Emerson
2011-11-23 0:47 ` NeilBrown [this message]
2011-11-23 3:50 ` Phil Turmel
2011-11-23 15:35 ` CoolCold
[not found] ` <CADzwnhUJ7HbZH9yqa6x9sHFLo8Vg=1k_SyzvZyq2=iQ5YRLhZQ@mail.gmail.com>
2011-11-23 22:36 ` NeilBrown
[not found] ` <CADzwnhXuW7ShBNGf+kqnZYrtRnWMPSRDWzb2h4Gt69Cih0-yGA@mail.gmail.com>
[not found] ` <CADzwnhUmHACPJA+c23AeRs3AW_ExuAUQST9jew_=5U1xdMqEFA@mail.gmail.com>
2011-12-03 17:02 ` Kenneth Emerson
[not found] ` <20111204061122.5bb5de4b@notabene.brown>
2011-12-04 17:20 ` Kenneth Emerson
2011-12-04 17:31 ` wilsonjonathan
2011-12-04 19:39 ` NeilBrown
2011-12-05 5:05 ` Kenneth Emerson
2011-11-23 22:38 ` Kenneth Emerson
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=20111123114743.1085889e@notabene.brown \
--to=neilb@suse.de \
--cc=kenneth.emerson@gmail.com \
--cc=linux-raid@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 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.