linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jon Nelson" <jnelson-linux-raid@jamponi.net>
To: Andre Noll <maan@systemlinux.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: raid5: degraded after reboot
Date: Fri, 12 Oct 2007 12:05:25 -0500	[thread overview]
Message-ID: <cccedfc60710121005n5290822g3bf463e653405b99@mail.gmail.com> (raw)
In-Reply-To: <20071012161809.GF21133@skl-net.de>

> You said you had to reboot your box using sysrq. There are chances you
> caused the reboot while all pending data was written to sdb4 and sdc4,
> but not to sda4. So sda4 appears to be non-fresh after the reboot and,
> since mdadm refuses to use non-fresh devices, it kicks sda4.

Can mdadm be told to use non-fresh devices?
What about sdb4: I can understand rewinding an event count (sorta),
but what does this mean:

mdadm: forcing event count in /dev/sdb4(1) from 327615 upto 327626

Since the array is degraded, there are 11 "events" missing from sdb4
(presumably sdc4 had them). Since sda4 is not part of the array, the
events can't be complete, can they?  Why jump *ahead* on events
instead of rewinding?


> Sure. I should have said: It's normal if one disk in a raid5 array is
> missing (or non-fresh).

I do not have a spare for this raid - I am aware of the risks and
mitigate them in other ways.

> To be precise, it means that the event counter for sda4 is less than
> the event counter on the other devices in the array. So mdadm must
> assume the data on sda4 is out of sync and hence the device can't be
> used. If you are not using bitmaps, there is no other way out than
> syncing the whole device, i.e. writing good data (computed from sdb4
> and sdc4) to sda4.
>
> Hope that helps.

Yes, that helps.

-- 
Jon

  reply	other threads:[~2007-10-12 17:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-12 15:38 raid5: degraded after reboot Jon Nelson
2007-10-12 15:47 ` Andre Noll
2007-10-12 16:08   ` Jon Nelson
2007-10-12 16:18     ` Andre Noll
2007-10-12 17:05       ` Jon Nelson [this message]
2007-10-12 18:32         ` Andre Noll
2007-10-12 18:58   ` Bill Davidsen

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=cccedfc60710121005n5290822g3bf463e653405b99@mail.gmail.com \
    --to=jnelson-linux-raid@jamponi.net \
    --cc=linux-raid@vger.kernel.org \
    --cc=maan@systemlinux.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).