linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Greaves <david@dgreaves.com>
To: Jan Engelhardt <jengelh@linux01.gwdg.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: RAID rebuild on Create
Date: Mon, 30 Apr 2007 21:12:21 +0100	[thread overview]
Message-ID: <46364DA5.3070409@dgreaves.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0704301958530.29151@yvahk01.tjqt.qr>

Jan Engelhardt wrote:
> Hi list,
> 
> 
> when a user does `mdadm -C /dev/md0 -l <any> -n <whatever fits> 
> <devices>`, the array gets rebuilt for at least RAID1 and RAID5, even if 
> the disk contents are most likely not of importance (otherwise we would 
> not be creating a raid array right now). Could not this needless resync 
> be skipped - what do you think?
> 
> 
> Jan

This is an FAQ - and I'll put it there RSN :)

Here's one answer from Neil from the archives (google "avoiding the initial
resync on --create"):

Otherwise I agree.  There is no real need to perform the sync of a
raid1 at creation.
However it seems to be a good idea to regularly 'check' an array to
make sure that all blocks on all disks get read to find sleeping bad
blocks early.  If you didn't sync first, then every check will find
lots of errors.  Ofcourse you could 'repair' instead of 'check'.  Or
do that once.  Or something.

For raid6 it is also safe to not sync first, though with the same
caveat as raid1.  Raid6 always updates parity by reading all blocks in
the stripe that aren't known and calculating P and Q.  So the first
write to a stripe will make P and Q correct for that stripe.
This is current behaviour.  I don't think I can guarantee it will
never changed.

For raid5 it is NOT safe to skip the initial sync.  It is possible for
all updates to be "read-modify-write" updates which assume the parity
is correct.  If it is wrong, it stays wrong.  Then when you lose a
drive, the parity blocks are wrong so the data you recover using them
is wrong.

In summary, it is safe to use --assume-clean on a raid1 or raid1o,
though I would recommend a "repair" before too long.  For other raid
levels it is best avoided.


      parent reply	other threads:[~2007-04-30 20:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-30 18:00 RAID rebuild on Create Jan Engelhardt
2007-04-30 18:19 ` Dan Williams
2007-04-30 18:35   ` Jan Engelhardt
2007-04-30 18:54     ` Patrick_Boyd
2007-04-30 19:27       ` Jan Engelhardt
2007-04-30 20:12 ` David Greaves [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=46364DA5.3070409@dgreaves.com \
    --to=david@dgreaves.com \
    --cc=jengelh@linux01.gwdg.de \
    --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).