Date: Sat, 14 Feb 1998 15:27:51 +1030 From: Greg Lehey <grog@lemis.com> To: Michael Hancock <michaelh@cet.co.jp> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: ccd and ftd Message-ID: <19980214152751.60811@freebie.lemis.com> In-Reply-To: <Pine.SV4.3.95.980214132603.12346A-100000@parkplace.cet.co.jp>; from Michael Hancock on Sat, Feb 14, 1998 at 01:38:47PM %2B0900 References: <19980214120247.43100@freebie.lemis.com> <Pine.SV4.3.95.980214132603.12346A-100000@parkplace.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 14 February 1998 at 13:38:47 +0900, Michael Hancock wrote:
> On Sat, 14 Feb 1998, Greg Lehey wrote:
>
>> On Sat, 14 February 1998 at 10:19:49 +0900, Michael Hancock wrote:
>>> I'm looking for a fault tolerant solution. I know Greg is working on a
>>> ftd driver.
>>>
>>> In the meantime I noticed that ccd supports mirroring. I'd like to mirror
>>> two arrays of 3 to 4 disk each. How well does this work?
>>
>> Do you mean more than one mirror? I don't believe that works.
>> Certainly I can't see how it can from reading the code.
>
> The man pages says you can mirror any even number of disks. What I'd like
> to do is this:
>
> 2940 - disk1 - disk2 - disk3 - disk4
>
> and mirror/duplex the whole array with another identical array.
>
> 2940 - disk5 - disk6 - disk7 - disk8
>
> Interestingly, man ccdconfig talks about CCDF_MIRROR and an unimplemented
> flag CCDF_PARITY.
Maybe we're talking at cross purposes here. The current version of
ccd supports two mappings:
1. Concatenation (in other words, making one large space out of
several smaller ones), which gives it the name. To concatenate,
you don't use any flags.
2. Mirroring (redundantly storing the same data on two different
spaces). To mirror, you specify the flag CCDF_MIRROR.
I haven't looked at ccdconfig(8), but I suspect that if you specify
more than one pair of disks on a CCDF_MIRROR line, it will concatenate
pairs of mirrors.
In addition, you can have striping, where the mapping is non-linear.
Every certain number of bytes (stripe size), the mapping proceeds to
the next component of the array, thus spreading the load more evenly.
I have some PostScript documentation of the comparisons under
development if anybody's interested.
The CCDF_PARITY flag was for Raid 5, but as you say, it hasn't been
implemented.
> Although, it looks like they have hooks for more fault-tolerant
> features in ccd I agree with your effort to make a separate
> fault-tolerant driver and keeping the ccd a light-weight, primarily
> for striping-only driver. Are you going to be able to share some
> code with it?
I'm a bit disappointed with CCD. I had originally planned just to
extend it, but I find it too primitive. It's not just "light
weight"--it's deficient. It handles faults very badly, and it offers
multiple possibilities for shooting yourself in the foot. In
addition, I don't think its performance is better than vinum (mine) is
going to be, though that remains to be seen. About the only advantage
is that it is significantly smaller, but I don't expect the typical
user of either driver to be concerned about another 20 kB of memory.
As a result of these problems, vinum is effectively a rewrite, though
I've been looking very carefully at CCD for implementation ideas.
Greg
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980214152751.60811>