From: Jon Buckingham <jbuckingham@blueyonder.co.uk>
To: Neil Brown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org, Jon Buckingham <jon.buckingham@hp.com>
Subject: Re: mdadm: making a spare actie
Date: Thu, 19 Jun 2008 23:24:13 +0100 [thread overview]
Message-ID: <485ADC8D.2010708@blueyonder.co.uk> (raw)
In-Reply-To: <18522.18111.182249.694308@notabene.brown>
[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]
Neil Brown wrote:
> On Thursday June 19, jbuckingham@blueyonder.co.uk wrote:
>> I have also done
>> mdadm /dev/md0 -a /dev/sdb5
>> and this results in a recovery...
>>
>> nas:~ # cat /proc/mdstat
>> Personalities : [raid6] [raid5] [raid4]
>> md0 : active raid5 sdb5[4] sda5[0] sdd5[3] sdc5[2]
>> 733142016 blocks level 5, 64k chunk, algorithm 2 [4/3] [U_UU]
>> [=>...................] recovery = 7.3% (17900780/244380672) finish=174.1min speed=21666K/sec
>>
>> unused devices: <none>
>>
>> Which I've been through before, but still ends up as a spare.
>
> That suggests that it hits some IO error during recovery and aborts.
>
> Are there any kernel log messages during the time that it is
> recovering?
>
> NeilBrown
>
>
No.
After the "add" completed, and a reboot it seems it is still a
"spare".
Strange.
Then from dmesg:
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
md: md0 stopped.
md: bind<sdc5>
md: bind<sdd5>
md: bind<sdb5>
md: bind<sda5>
md: kicking non-fresh sdb5 from array!
md: unbind<sdb5>
md: export_rdev(sdb5)
raid5: automatically using best checksumming function: pIII_sse
pIII_sse : 5640.000 MB/sec
raid5: using function: pIII_sse (5640.000 MB/sec)
raid5: device sda5 operational as raid disk 0
raid5: device sdd5 operational as raid disk 3
raid5: device sdc5 operational as raid disk 2
raid5: allocated 4204kB for md0
raid5: raid level 5 set md0 active with 3 out of 4 devices, algorithm 2
RAID5 conf printout:
--- rd:4 wd:3
disk 0, o:1, dev:sda5
disk 2, o:1, dev:sdc5
disk 3, o:1, dev:sdd5
I am tempted to rebuild the whole thing now, since I have tried
quite a few variations and not solved it. There must be some deeper rooted problem that
is causing this issue on the disk.
Thanks again,
Jon B
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3281 bytes --]
next prev parent reply other threads:[~2008-06-19 22:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-19 9:23 mdadm: making a spare actie Jon Buckingham
2008-06-19 11:45 ` Neil Brown
2008-06-19 22:24 ` Jon Buckingham [this message]
2008-06-20 0:33 ` Neil Brown
2008-06-20 8:57 ` Jon Buckingham
2008-06-20 22:18 ` Jon Buckingham
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=485ADC8D.2010708@blueyonder.co.uk \
--to=jbuckingham@blueyonder.co.uk \
--cc=jon.buckingham@hp.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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).