Design and implementation of GEOM_MIRROR:)

[Pawel Jakub Dawidek]

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.
+> 
+> Any policy can be implemented with dedicated hot spares, but at a
+> cost in disk-space.
+> 
+> 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.
+> 
+> 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...

-- 
Pawel Jakub Dawidek                       http://www.FreeBSD.org
pjd at FreeBSD.org                           http://garage.freebsd.pl
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20040707/22fc4189/attachment.bin