linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 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).