linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Erik Mouw <erik@harddisk-recovery.com>
To: linux-raid mailing list <linux-raid@vger.kernel.org>
Subject: Re: avoiding the initial resync on --create
Date: Mon, 9 Oct 2006 15:49:46 +0200	[thread overview]
Message-ID: <20061009134946.GA26122@harddisk-recovery.com> (raw)
In-Reply-To: <20061009125700.GA10191@piper.madduck.net>

On Mon, Oct 09, 2006 at 02:57:00PM +0200, martin f krafft wrote:
> I am looking at http://bugs.debian.org/251898 and wondering whether
> it is save to use --assume-clean (which prevents the initial resync)
> when creating RAID arrays from the Debian installer.
> 
> Please also see the following discussion on IRC:
> 
> < madduck> yeah, i am not sure --assume-clean is a good idea.
> < peterS> madduck: why not?  I've tried to think of a reason it
>   would fail for months, and so far I'm too stupid to think of one
> < madduck> even then
> < madduck> peterS: because it then assumes that it
> < madduck> it's clean, period.
> < peterS> yeah, so?
> < peterS> the blocks you have not written will have unreliable
>   contents
> < madduck> in reality, the three components are not properly XORed
> < peterS> but why would you care about that?
> < madduck> hm. kinda true.
> < peterS> the blocks you _do_ write will be correct
> < peterS> even an uninitialised raid5 or raid6 seems like it would
>   work perfectly well with --assume-clean

There is no way to figure out what exactly is correct data and what is
not. It might work right after creation and during the initial install,
but after the next reboot there is no way to figure out what blocks to
believe.

> Do you have any thoughts on the issue? If Debian were to --create
> its arrays with --assume-clean just before slapping a filesystem on
> them and installing the system, do you see any potential problems?

If you want to speed up the initial install, I'd say it's better to
create the array with one missing drive, install the system and let it
resync upon the next boot. Be sure to tell the user about that, though.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

  reply	other threads:[~2006-10-09 13:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-09 12:57 avoiding the initial resync on --create martin f krafft
2006-10-09 13:49 ` Erik Mouw [this message]
2006-10-09 16:32   ` Doug Ledford
2006-10-09 19:10     ` Rob Bray
2006-10-09 19:45       ` Doug Ledford
2006-10-09 21:33         ` Neil Brown
2006-10-09 21:45           ` Doug Ledford
2006-10-09 23:14             ` Neil Brown
2006-10-11 21:24         ` Michael Tokarev
2006-10-10  9:55     ` Gabor Gombas
2006-10-10 17:47       ` Doug Ledford
2006-10-10 19:18         ` Sergey Vlasov
2006-10-10 20:38           ` Doug Ledford
2006-10-10 20:37         ` Gabor Gombas
2006-10-10 21:26           ` Doug Ledford
2006-10-10 22:14             ` Rev. Jeffrey Paul

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=20061009134946.GA26122@harddisk-recovery.com \
    --to=erik@harddisk-recovery.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).