From: Michael Evans <mjevans1983@gmail.com>
To: Brett Russ <bruss@netezza.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: non-fresh data unavailable bug
Date: Thu, 14 Jan 2010 11:24:03 -0800 [thread overview]
Message-ID: <4877c76c1001141124m1d3fcfcdmffc3df97d1b504a@mail.gmail.com> (raw)
In-Reply-To: <hinc60$fnh$1@ger.gmane.org>
On Thu, Jan 14, 2010 at 7:10 AM, Brett Russ <bruss@netezza.com> wrote:
> Slightly related to my last message here Re:non-fresh behavior, we have seen
> cases where the following happens:
> * healthy 2 disk raid1 (disks A & B) incurs a problem with disk B
> * disk B is removed, unit is now degraded
> * replacement disk C is added; recovery from A to C begins
> * during recovery, disk A incurs a brief lapse in connectivity. At this
> point C is still up yet only has a partial copy of the data.
> * a subsequent assemble operation on the raid1 results in disk A being
> kicked out as non-fresh, yet C is allowed in.
>
> This presents quite a data-unavailability problem and basically requires
> recognizing the situation and hand assembling the array with disk A (only)
> first, then adding C back in. Unfortunately this situation is hard to
> reproduce and we don't have a dump of the 'mdadm --examine' output for it
> yet.
>
> Any thoughts on this while we try to get a better reproduction case?
>
> Thanks,
> Brett
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
I believe the desired and logical behavior here is to refuse running
an incomplete array unless explicitly forced to do so. Incremental
assembly might be what you're seeing.
The only way to access the data from those devices, presuming that
without the device that had the hiccup your array is incomplete, would
be to force assembly with the older device included and hope. I very
much recommend running it read-only until you can determine which
assembly pattern produces the most viable results.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-01-14 19:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-14 15:10 non-fresh data unavailable bug Brett Russ
2010-01-14 19:24 ` Michael Evans [this message]
2010-01-15 15:36 ` Brett Russ
2010-01-18 3:32 ` Neil Brown
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=4877c76c1001141124m1d3fcfcdmffc3df97d1b504a@mail.gmail.com \
--to=mjevans1983@gmail.com \
--cc=bruss@netezza.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).