From: NeilBrown <neilb@suse.de>
To: lists@xunil.at
Cc: linux-raid@vger.kernel.org
Subject: Re: Re-adding disks to RAID6 in a Fujitsu NAS: old mdadm?
Date: Fri, 29 Jun 2012 07:36:32 +1000 [thread overview]
Message-ID: <20120629073632.61f529a8@notabene.brown> (raw)
In-Reply-To: <4FECA1A8.7090608@xunil.at>
[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]
On Thu, 28 Jun 2012 20:25:44 +0200 "Stefan G. Weichinger" <lists@xunil.at>
wrote:
> Am 28.06.2012 17:56, schrieb Stefan G. Weichinger:
>
> > md0 : active raid6 sdb3[4](S) sda3[5] sdc3[2] sdd3[3]
> > 3903891200 blocks level 6, 64k chunk, algorithm 2 [4/2] [__UU]
> > [================>....] recovery = 83.0%
> > (1621636224/1951945600) finish=81.5min speed=67477K/sec
> >
> > I assume it is OK in this state of things that sdb3 is marked as
> > (S)pare ...
>
> It seems so, as now it has entered the next stage:
>
> md0 : active raid6 sdb3[4] sda3[0] sdc3[2] sdd3[3]
> 3903891200 blocks level 6, 64k chunk, algorithm 2 [4/3] [U_UU]
> [=>...................] recovery = 6.2% (122751744/1951945600)
> finish=784.6min speed=38854K/sec
>
> Somewhat slower, but no (S)pare there anymore.
>
> What is the logic behind that?
As you have guessed, it first recovered one device, then recovered the second
one.
But it looks like there are no read errors on the two good devices, so
fear-not.
>
> What does it do exactly when it re-adds the first disk, what in the
> second round?
>
> Should I have added sd[ab]3 in one command?
Had you done that with a very new mdadm, it would have recovered both at once.
mdadm has to say:
- disable recovery for now
- here is one new spare
- here is another spare
- ok, you can try recovery now
otherwise as soon as it gets one spare it will start recovery.
>
> To me it also seems that I now have good redundancy again already, correct?
Correct. You have single redundancy and in about 10 hours since your email
you'll have double redundancy.
>
> Sorry for all my questions ;-)
> I just like to understand things, at least on my user-level.
>
> Stefan
No problem.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-06-28 21:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-26 13:57 Re-adding disks to RAID6 in a Fujitsu NAS: old mdadm? Stefan G. Weichinger
2012-06-27 10:17 ` Stefan G. Weichinger
2012-06-27 11:34 ` Stefan G. Weichinger
2012-06-27 11:38 ` Stefan G. Weichinger
2012-06-28 6:32 ` NeilBrown
2012-06-28 8:59 ` Stefan G. Weichinger
2012-06-28 9:14 ` Stefan G. Weichinger
2012-06-28 9:23 ` Stefan G. Weichinger
2012-06-28 11:22 ` NeilBrown
2012-06-28 15:56 ` Stefan G. Weichinger
2012-06-28 18:25 ` Stefan G. Weichinger
2012-06-28 21:36 ` NeilBrown [this message]
2012-06-29 8:18 ` Stefan G. Weichinger
2012-07-02 8:30 ` Stefan G. Weichinger
2012-06-28 21:39 ` NeilBrown
2012-06-28 9:39 ` NeilBrown
2012-06-28 9:42 ` Stefan G. Weichinger
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=20120629073632.61f529a8@notabene.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--cc=lists@xunil.at \
/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).