From: joystick <joystick@shiftmail.org>
To: Brad Campbell <lists2009@fnarfbargle.com>
Cc: NeilBrown <neilb@suse.de>, Mikael Abrahamsson <swmike@swm.pp.se>,
linux-raid@vger.kernel.org
Subject: Re: is "replaceable" in 3.2 considered stable
Date: Wed, 07 Nov 2012 19:08:48 +0100 [thread overview]
Message-ID: <509AA3B0.70607@shiftmail.org> (raw)
In-Reply-To: <509A65CF.8020409@fnarfbargle.com>
On 11/07/12 14:44, Brad Campbell wrote:
> On 07/11/12 17:55, joystick wrote:
>
>>
>> we still need someone to test the other case, a more common scenario I'd
>> say: the disk to be replaced fails during hot-replace
>
> I suspect I can do that by creating some "media errors" using hdparm
> while the replacement is in progress.
Hi Brad
That seems to be one way, but only for read errors, another would be
with dm-flakey, which AFAIU would also allow to fail writes, and the
faulty raid type (man mdadm)
the last two should allow to also test with write failures and hence
complete failure of the source disk which should interrupt hotreplace
and fallback to normal rebuild (I don't know if restarting from first
byte or more intelligently going ahead with rebuild from the point of
failure of hot-replace).
Then, the presence of the bad-blocks-list also changes the behaviour of
hot-replace, so that one also would have to be tested if you are
interested, so that makes already a lot of cases:
- read error only or readwrite error in source device
- presence of bad-block-list yes/no
(4 cases)
- write error of destination device
- power loss in the middle of hot-replace
- bad-blocks set for many devices (more than parity or mirror level) all
on the same strip (4k wide) including the disk to be replaced, which
AFAIR should cause a corresponding bad-block hole in the device
destination of hotreplace, which in turn would cause read-error to be
returned immediately by MD if that area is read.
- simultaneous hot-replace of 2+ drives; I don't know if this is
supposed to work...
> If you put together a set of tests you'd like performed I'll be happy
> to run them and see what happens. The machine is on a managed APC PDU
> (yay Gumtree!), so remote power cycling is a lot easier than it used
> to be and I really don't mind hammering the disks with emergency parks
> or excessive cycles.
Did that :-P
I'll tell you if some other test comes to my mind
Thanks for your work
prev parent reply other threads:[~2012-11-07 18:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-05 4:51 is "replaceable" in 3.2 considered stable Mikael Abrahamsson
2012-11-05 5:22 ` NeilBrown
2012-11-05 8:11 ` Mikael Abrahamsson
2012-11-05 8:42 ` NeilBrown
2012-11-05 8:46 ` Mikael Abrahamsson
2012-11-05 10:53 ` NeilBrown
2012-11-05 10:56 ` Mikael Abrahamsson
2012-11-07 1:42 ` Brad Campbell
2012-11-07 9:55 ` joystick
2012-11-07 13:44 ` Brad Campbell
2012-11-07 18:08 ` joystick [this message]
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=509AA3B0.70607@shiftmail.org \
--to=joystick@shiftmail.org \
--cc=linux-raid@vger.kernel.org \
--cc=lists2009@fnarfbargle.com \
--cc=neilb@suse.de \
--cc=swmike@swm.pp.se \
/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).