From: hank peng <pengxihan@gmail.com>
To: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: about raid5 recovery when created
Date: Tue, 8 Dec 2009 22:03:09 +0800 [thread overview]
Message-ID: <389deec70912080603w47d7fda3jf021af169ac1c48c@mail.gmail.com> (raw)
In-Reply-To: <20091208135600.GB21130@cthulhu.home.robinhill.me.uk>
2009/12/8 Robin Hill <robin@robinhill.me.uk>:
> On Tue Dec 08, 2009 at 09:49:48PM +0800, hank peng wrote:
>
>> 2009/12/8 Robin Hill <robin@robinhill.me.uk>:
>> > On Tue Dec 08, 2009 at 09:01:23PM +0800, hank peng wrote:
>> >
>> >> Hi, all:
>> >> As we know, when a raid5 array is created, recovery will be going on
>> >> which involves some read, one xor and one write. Since there is no
>> >> real data in the disk at the time, besides, if I am willing to wait
>> >> for recovery to complete and then use this raid5, how about adding
>> >> support for a fast recovery method? Right now, what is in my mind is
>> >> zero all disks which belong to this raid5. I think it will increase
>> >> raid5 recovery speed when created and decrease CPU usage, since all
>> >> zero is also XORed.
>> >> What do raid developers think?
>> >>
>> > It'll decrease CPU usage but increase I/O - you're now needing to write
>> > to all disks. Most systems will be I/O limited rather than CPU limited,
>> > so the current approach works better. If you want to zero the disks
>> > then do this before creating the array - you can then use --assume-clean
>> > to skip the resync process.
>> >
>> I think --assume-clean is used mostly when doing performance test and
>> can't be used when creating a raid5 array using new disk, because
>> later read and write operation make assumption that all stripe is
>> XORed. Correct me if I am wrong.
>>
> You're correct - that's why I said to zero all the disks first so the
> XOR data is all correct.
>
I think this function is better to be implemented in kernel raid
layer, not in user space(for example using dd command).
In this way, we can get good performance and lower cpu usage, also, we
can make this function be part of raid code so that it can be managed
by mdadm
> Cheers,
> Robin
> --
> ___
> ( ' } | Robin Hill <robin@robinhill.me.uk> |
> / / ) | Little Jim says .... |
> // !! | "He fallen in de water !!" |
>
--
The simplest is not all best but the best is surely the simplest!
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-12-08 14:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-08 13:01 about raid5 recovery when created hank peng
2009-12-08 13:14 ` Robin Hill
2009-12-08 13:49 ` hank peng
2009-12-08 13:56 ` Robin Hill
2009-12-08 14:03 ` hank peng [this message]
2009-12-09 8:30 ` Michael Evans
2009-12-09 11:29 ` hank peng
2009-12-10 1:43 ` Neil Brown
2009-12-10 3:34 ` Michael Evans
2009-12-10 3:59 ` Neil Brown
[not found] ` <g3143w7eigolu0x2ziUYAxe124vaj_firegpg@mail.gmail.com>
2009-12-30 2:55 ` Neil Brown
[not found] ` <389deec70912090330l73d04696v1d23dbe74423d15b@mail.gmail.com>
2009-12-09 23:29 ` Michael Evans
2009-12-08 13:52 ` hank peng
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=389deec70912080603w47d7fda3jf021af169ac1c48c@mail.gmail.com \
--to=pengxihan@gmail.com \
--cc=linux-raid@vger.kernel.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).