From: Neil Brown <neilb@cse.unsw.edu.au>
To: Martin Bene <martin.bene@icomedias.com>
Cc: Jason Pfingstmann <stclists@wearesimply.com>, linux-raid@vger.kernel.org
Subject: Re: AW: Raid 5 and Power Failure
Date: Mon, 15 Jul 2002 10:29:18 +1000 (EST) [thread overview]
Message-ID: <15666.5982.13238.264260@notabene.cse.unsw.edu.au> (raw)
In-Reply-To: message from Martin Bene on Saturday July 13
On Saturday July 13, martin.bene@icomedias.com wrote:
> Hi Neil, Jason
>
> > Get mdadm
> > http://www.cse.unsw.edu.au/~neilb/source/mdadm/
> >
> > and use
> > mdadm --assemble --force /dev/md0 /dev/hd......
>
> shouldn't /dev/hda be left out of the list here? since it looks like hda
> really is out out date I think you'd get best results by using only the most
> up-to-date disks.
hda certainly could be left out, but the point of "mdadm -Af" is that
it tried to do the "best" thing. You don't *need* to figure out in
too much detail what has gone wrong. It will pick the best available
drives and use them.
>
> Also, when using the mkraid -force method that had to be used before mdadm, I
> always recommended leaving out all spare disks and one of the data disks,
> forcing the array to be (re)created in degraded mode. that way, write
> operations to the disks are kept to a minimum and it's possible to retry if
> you made an error (wrong disk left out etc).
>
> would it make sense to treat mdadm similarely, i.e only provide enough
> devices to assemble a degraded array and hotadd the final device after the
> array checks out ok? I don't like the idea of background parity rebuild
> kicking in before I've had a chance to check things out.
In general I would agree with that.
I would actually like to be able to start an array in "read-only" mode
and have no rebuild/resync happen until it got switched to write
only. This may well happen in 2.6.
NeilBrown
next prev parent reply other threads:[~2002-07-15 0:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-13 10:01 AW: Raid 5 and Power Failure Martin Bene
2002-07-15 0:29 ` Neil Brown [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-07-14 1:43 simply service
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=15666.5982.13238.264260@notabene.cse.unsw.edu.au \
--to=neilb@cse.unsw.edu.au \
--cc=linux-raid@vger.kernel.org \
--cc=martin.bene@icomedias.com \
--cc=stclists@wearesimply.com \
/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).