[src/trunk]: src/sbin/raidctl Document the need for zeroing out the first 64 ...

[buhrow <buhrow%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/e8ad0f6b54b0
branches:  trunk
changeset: 767740:e8ad0f6b54b0
user:      buhrow <buhrow%NetBSD.org@localhost>
date:      Thu Jul 28 18:25:22 2011 +0000

description:
Document the need for zeroing out the first 64 blocks of a replacement
component in a failed RAID set in order to avoid potentially configuring
RAId 1 sets with erroneous values taken from random extent data in the
replacement component partitions.

diffstat:

 sbin/raidctl/raidctl.8 |  14 +++++++++++++-
 1 files changed, 13 insertions(+), 1 deletions(-)

diffs (27 lines):

diff -r 70b61f2526e0 -r e8ad0f6b54b0 sbin/raidctl/raidctl.8
--- a/sbin/raidctl/raidctl.8    Thu Jul 28 17:33:55 2011 +0000
+++ b/sbin/raidctl/raidctl.8    Thu Jul 28 18:25:22 2011 +0000
@@ -1,4 +1,4 @@
-.\"     $NetBSD: raidctl.8,v 1.61 2010/01/27 09:26:16 wiz Exp $
+.\"     $NetBSD: raidctl.8,v 1.62 2011/07/28 18:25:22 buhrow Exp $
 .\"
 .\" Copyright (c) 1998, 2002 The NetBSD Foundation, Inc.
 .\" All rights reserved.
@@ -1597,5 +1597,17 @@
 additional space and speed, than it is to use parity, but
 not keep the parity correct.
 At least with RAID 0 there is no perception of increased data security.
+.Pp
+When replacing a failed component of a RAID set, it is a good
+idea to zero out the first 64 blocks of the new component to insure the
+RAIDframe driver doesn't erroneously detect a component label in the 
+new component.  This is particularly true on
+.Em
+RAID 1
+sets because there is at most one correct component label in a failed RAID
+1 installation, and the RAIDframe driver picks the component label with the
+highest serial number and modification value as the authoritative source
+for the failed RAID set when choosing which component label to use to
+configure the RAID set.
 .Sh BUGS
 Hot-spare removal is currently not available.