linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Accetta <maccetta@laurelnetworks.com>
To: linux-raid@vger.kernel.org
Subject: RAID1, hot-swap and boot integrity
Date: Fri, 02 Mar 2007 09:04:40 -0500	[thread overview]
Message-ID: <45E82EF8.9000106@laurelnetworks.com> (raw)

We are using a RAID1 setup with two SATA disks on x86, using the whole
disks as the array components.  I'm pondering the following scenario.
We will boot from whichever drive the BIOS has first in its boot list
(the other drive will be second).  In the steady state this choice is
immaterial.  However, if after we boot that first drive fails and has
to be hot-swapped *and* the system crashes or is rebooted while the
re-sync operation is still running, it seems possible (perhaps even
likely) that the BIOS will to choose to boot from the same disk slot.
However, the drive in that slot is still being recovered and may not be
intact enough to boot from yet.

I've been considering trying something like having the re-sync algorithm
on a whole disk array defer the copy for sector 0 to the very end of the
re-sync operation.  Assuming the BIOS makes at least a minimal consistency
check on sector 0 before electing to boot from the drive, this would keep
it from selecting a partially re-sync'd drive that was not previously bootable.
Another wrinkle might be to also have re-sync zap sector 0 initially so that
a previously bootable disk added as the replacement would not be booted
in an inconsistent state, although this could not eliminate the window
in which a crash or reboot before the re-sync even started could cause
the replacement disk with who knows what contents to be booted.    This
also seems a fairly x86 centric solution, although that is fine for our
current application which is x86-based.

Thoughts or other suggestions anyone?
-- 
Mike Accetta

ECI Telecom Ltd.
Data Networking Division (previously Laurel Networks)

             reply	other threads:[~2007-03-02 14:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-02 14:04 Mike Accetta [this message]
2007-03-02 15:40 ` RAID1, hot-swap and boot integrity Justin Piszcz
2007-03-02 16:02   ` Gabor Gombas
2007-03-02 16:10 ` Gabor Gombas
2007-03-02 20:57   ` Bill Davidsen
2007-03-04 17:31 ` H. Peter Anvin
     [not found] ` <9782.20070302161004.GE31010@boogie.lpds.sztaki.hu>
2007-03-05 23:32   ` Mike Accetta
2007-03-06 10:01     ` Gabor Gombas
     [not found] ` <12470.45E88FAA.5020106@tmr.com>
2007-03-05 23:38   ` Mike Accetta
2007-03-06 23:17     ` Bill Davidsen
2007-03-07 20:48     ` H. Peter Anvin
     [not found] ` <12721.45EB026B.1040503@zytor.com>
2007-03-05 23:47   ` Mike Accetta
2007-03-05 23:55     ` H. Peter Anvin
2007-03-06 23:18       ` Bill Davidsen

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=45E82EF8.9000106@laurelnetworks.com \
    --to=maccetta@laurelnetworks.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).