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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.