From owner-freebsd-geom@FreeBSD.ORG Wed Jul 7 00:57:20 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72A6C16A4CE; Wed, 7 Jul 2004 00:57:20 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14B2643D53; Wed, 7 Jul 2004 00:57:20 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 7B499ACAF1; Wed, 7 Jul 2004 02:57:18 +0200 (CEST) Date: Wed, 7 Jul 2004 02:57:18 +0200 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20040707005718.GO12007@darkness.comp.waw.pl> References: <20040706183727.GN12007@darkness.comp.waw.pl> <20837.1089143337@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wMeKMKLo7/XXP2hN" Content-Disposition: inline In-Reply-To: <20837.1089143337@critter.freebsd.dk> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: geom@FreeBSD.org cc: Scott Long Subject: Re: Design and implementation of GEOM_MIRROR:) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2004 00:57:20 -0000 --wMeKMKLo7/XXP2hN Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 06, 2004 at 09:48:57PM +0200, Poul-Henning Kamp wrote: +> Dedicated hot sparing is when an array has an extra disk member +> which is dedicated as a hot spare and nobody else can use it. This +> is what you use to have when you have very strict rules for which +> bits are the most important etc. +>=20 +> Any policy can be implemented with dedicated hot spares, but at a +> cost in disk-space. +>=20 +> It is straightforward to implement and I think that it would be +> fair to require all of our array classes to support it. But it still will be good to have generalized API to do it and we can also support dedication to more than one array. For example I've disks da0, da1, da2, da3, I run mirror on da0+da1 and da2+da3 and I stripe da0+da1 with da2+da3. I've also da4 which I want to use as a spare disk for da0+da1 mirror _or_ da2+da3 mirror, but not for other mirrors in the system. +> 3. We need some way to partition hot spares. If I dedicate an +> entire 72G disk as hot spare and an array need only 10G of +> hot spare, the remaining 62G should be available for other +> hot sparing uses. I thought about this and I have to disagree. It'll be just too complex. Imagine a situation when we need those 10G for mirror1, so first 10G is reserved for it, then we need 40G for mirror2, so we give it, then another 10G is requested by mirror3, ok go ahead and then mirror2 doesn't need his spare any more, so we have a hole in our spare provider. What should we do if someone requests for 50G? (And I don't think, that concatenating all fragments is a good way to go.) So, in my opinion, administrator should be just aware of this and prepare providers which can be needed. +> Considering the complexity of this, I am pretty sure that pooled +> spares do not belong in the kernel. It would be much better handled +> by a userland process where the user could configure (using a +> scripting language ?) how hot sparing decisions are to be made. +>=20 +> To do it in userland, would require standardization of the g_ctl() +> messages to the arrays and a way for the arrays to signal to the +> userland process that they are in distress. The former is merely +> a matter of discipline, the latter we can use the XML output for. I'm not sure about this... --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --wMeKMKLo7/XXP2hN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA60puForvXbEpPzQRAtneAJ9GpluNRi4aLa3o2Wi4/N2wo1hd/QCggFou 9QlAq3TJ6NOpMhA3pPLAuhw= =hsPC -----END PGP SIGNATURE----- --wMeKMKLo7/XXP2hN--