kern/79035: gvinum unable to create a striped set of mirrored sets/plexes

[Greg 'groggy' Lehey]

The following reply was made to PR kern/79035; it has been noted by GNATS.

From: Greg 'groggy' Lehey <grog at FreeBSD.org>
To: Sven Willenberger <sven at dmv.com>
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: kern/79035: gvinum unable to create a striped set of mirrored sets/plexes
Date: Sun, 20 Mar 2005 13:41:01 +1030

 --RASg3xLB4tUQ4RcS
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 [Format recovered--see http://www.lemis.com/email/email-format.html]
 
 Single line paragraphs.  Please limit your lines to < 80 characters.
 
 On Sunday, 20 March 2005 at  2:04:34 +0000, Sven Willenberger wrote:
 >
 > Under the current implementation of gvinum it is possible to create
 > a mirrored set of striped plexes but not a striped set of mirrored
 > plexes. For purposes of resiliency the latter configuration is
 > preferred as illustrated by the following example:
 >
 > Use 6 disks to create one of 2 different scenarios.
 >
 > 1) Using the current abilities of gvinum create 2 striped sets using
 > 3 disks each: A1 A2 A3 and B1 B2 B3 then create a mirror of those 2
 > sets such that A(123) mirrors B(123). In this situation if any drive
 > in Set A fails, one still has a working set with Set B. If any drive
 > now fails in Set B, the system is shot.
 
 No, this is not correct.  The plex ("set") only fails when all drives
 in it fail.
 
 > 2) Using the proposed added ability to create 3 mirror sets A1 and
 > B1, A2 and B2, A3 and B3. Now create a stripe set across all three
 > mirrors. Now we can have a situation where one of the "A" drives
 > fail (for example A1). Then we can also have one of the "B" drives
 > fail and, as long as it is not "B1" in this case, we still have a
 > functioning array.
 
 Agreed.  So there's no difference.
 
 > Thus the striping of mirrors (rather than a mirror of striped sets)
 > is a more resilient and fault-tolerant setup of a multi-disk array.
 
 No, you're misunderstanding the current implementation.
 
 This is a change request, so I'm not closing (or even assigning to
 myself) the PR.
 
 Greg
 --
 When replying to this message, please take care not to mutilate the
 original text.
 For more information, see http://www.lemis.com/email.html
 Finger grog at FreeBSD.org for PGP public key.
 See complete headers for address and phone numbers.
 
 --RASg3xLB4tUQ4RcS
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.6 (FreeBSD)
 
 iD8DBQFCPOnFIubykFB6QiMRAm1BAJsGIfr1v4ILlB4CNBP1t/o67WxYWACePZXj
 tN2nu75BDBDu5SoDMGB+0BI=
 =UiI5
 -----END PGP SIGNATURE-----
 
 --RASg3xLB4tUQ4RcS--