[src/trunk]: src/sys/dev/raidframe Add a comment to clarify why we actually w...

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

details:   https://anonhg.NetBSD.org/src/rev/576861e06538
branches:  trunk
changeset: 486713:576861e06538
user:      oster <oster%NetBSD.org@localhost>
date:      Sat May 27 19:12:03 2000 +0000

description:
Add a comment to clarify why we actually want the component label to
be considered a 'match' even if the mod_counter is wrong.

diffstat:

 sys/dev/raidframe/rf_netbsdkintf.c |  13 ++++++++++++-
 1 files changed, 12 insertions(+), 1 deletions(-)

diffs (27 lines):

diff -r 34dadcebeb82 -r 576861e06538 sys/dev/raidframe/rf_netbsdkintf.c
--- a/sys/dev/raidframe/rf_netbsdkintf.c        Sat May 27 19:02:54 2000 +0000
+++ b/sys/dev/raidframe/rf_netbsdkintf.c        Sat May 27 19:12:03 2000 +0000
@@ -1,4 +1,4 @@
-/*     $NetBSD: rf_netbsdkintf.c,v 1.80 2000/05/27 18:23:27 oster Exp $        */
+/*     $NetBSD: rf_netbsdkintf.c,v 1.81 2000/05/27 19:12:03 oster Exp $        */
 /*-
  * Copyright (c) 1996, 1997, 1998 The NetBSD Foundation, Inc.
  * All rights reserved.
@@ -2890,6 +2890,17 @@
 
            (clabel1->mod_counter == clabel2->mod_counter) &&
 
+          The reason we don't check for this is that failed disks
+          will have lower modification counts.  If those disks are
+          not added to the set they used to belong to, then they will
+          form their own set, which may result in 2 different sets,
+          for example, competing to be configured at raid0, and
+          perhaps competing to be the root filesystem set.  If the
+          wrong ones get configured, or both attempt to become /,
+          weird behaviour and or serious lossage will occur.  Thus we
+          need to bring them into the fold here, and kick them out at
+          a later point.
+
        */
 
        clabel1 = cset->ac->clabel;