From: Phil Turmel <philip@turmel.org>
To: hansbkk@gmail.com
Cc: Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: Mixing mdadm versions
Date: Thu, 17 Feb 2011 08:25:14 -0500 [thread overview]
Message-ID: <4D5D21BA.6060804@turmel.org> (raw)
In-Reply-To: <AANLkTi=g2V9n_AEEGX58d1PkTLRj7HtxT=AGEaLQXNz1@mail.gmail.com>
On 02/17/2011 05:21 AM, hansbkk@gmail.com wrote:
> I've created and manage sets of arrays with mdadm v3.1.4 - I've been
> using System Rescue CD and Grml for my sysadmin tasks, as they are
> based on fairly up-to-date gentoo and debian and have a lot of
> convenient tools not available on the production OS, a "stable" (read:
> old packages) flavor of RHEL, which turns out is running mdadm v2.6.4.
> I spec'd v1.2 metadata for the big raid6 storage arrays, but kept to
> 0.90 for the smaller raid1's as some of those are my boot devices.
The default data offset for for v1.1 and v1.2 meta-data changed in mdadm v3.1.2. If you ever need to use the running system to "mdadm --create --assume-clean" in a recovery effort, the data segments will *NOT* line up if the original array was created with a current version of mdadm.
(git commit a380e2751efea7df "super1: encourage data alignment on 1Meg boundary")
> As per a previous thread, I've noticed on the production OS the output
> of mdadm -E on a member returns a long string of "failed, failed". The
> more modern mdadm reports everything's OK.
>
> - Also mixed in are some "fled"s - whazzup with that?
>
> Unfortunately the server is designed to run as a packaged appliance
> and uses the rpath/conary package manager, so I'm hesitant to fiddle
> around upgrading some bits, afraid that other bits will break - the
> sysadmin tools are run from a web interface to a bunch of PHP scripts.
>
> So, here are my questions:
>
> As long as the more recent versions of mdadm report that everything's
> OK, can I ignore the mishmosh output of the older mdadm -E report?
Don't know.
> And am I correct in thinking that from now on I should create
> everything with the older native packages that are actually going to
> serve the arrays in production?
If there's a more modern Red Hat mdadm package that you can include in your appliance, that would be my first choice. After testing with the web tools, though.
Otherwise, I would say "Yes", for the above reason. However, the reverse problem can also occur. You won't be able to use a modern mdadm to do a "--create --assume-clean" on an offline system. That's what happened to Simon in another thread. Avoiding that might be worth the effort qualifying a newer version of mdadm.
Phil
next prev parent reply other threads:[~2011-02-17 13:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-17 10:21 Mixing mdadm versions hansbkk
2011-02-17 13:25 ` Phil Turmel [this message]
2011-02-17 14:16 ` hansbkk
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=4D5D21BA.6060804@turmel.org \
--to=philip@turmel.org \
--cc=hansbkk@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.