Date: Mon, 28 Jan 2002 13:18:34 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: arch@FreeBSD.ORG Subject: Re: Geom project, limited preview... Message-ID: <20020128131834.A4983@panzer.kdm.org> In-Reply-To: <45940.1012245195@critter.freebsd.dk>; from phk@critter.freebsd.dk on Mon, Jan 28, 2002 at 08:13:15PM %2B0100 References: <20020128111514.A3819@panzer.kdm.org> <45940.1012245195@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 28, 2002 at 20:13:15 +0100, Poul-Henning Kamp wrote: > In message <20020128111514.A3819@panzer.kdm.org>, "Kenneth D. Merry" writes: > > >Looks interesting. > > > >If you end up doing any striping, mirroring or RAID with this, I would > >suggest/request you put hooks in for: > > > > - different on-disk metadata types. There is a specific project I've been > > working on (not for FreeBSD, unfortunately) that involves changing a > > software RAID implementation to have support for multiple types of on-disk > > metadata. > > My plan was to recognize what I can, and have a way for userland to configure > as well. The main thing is that you design the metadata handling code so that additional metadata types can be added later without too much trouble. This will require thought, especially for multilevel array types. e.g., I know of two different Adaptec metadata types that handle multilevel arrays in different ways. With the first, everything is spelled out in one chunk of metadata at the end of each physical disk. If you've got a RAID-10, it defines the RAID-1 arrays and the RAID-0 stripe set over the RAID-1 arrays. With the second, each level is defined by metadata at the beginning of the component piece. So with a RAID-10, the physical disk would have information about the RAID-1 array at the beginning. The RAID-1 array would have information about the RAID-0 array at the beginning. Depending on your design, it may be easier to deal with one type of multilevel metadata than another. The key is to remember that both exist, and may need to be supported at some point. So you want to design your metadata handling code and your array autoconfiguration code so that you can deal with either arrangement. > > - support for external parity engines for RAID-5 parity calculation. (If > > you do any sort of RAID-5 with this.) > > Well, I have no raid-5 hardware so this would probably have to be left > to somebody else. I only requested "hooks", not actual support. :) Adaptec makes some boards, the AAA series, that would be able to use software RAID with hooks for an external parity engine. They haven't made any new designs with that architecture since the Ultra-2 days, though. You'll probably also want to put in hooks for choosing the fastest parity calculation routine for a given machine. (Since you may want to write assembly versions for MMX, SSE, etc., capable processors.) > >Another interesting thing you could do with this would be tied in with your > >"COW" proposal. In essence, you could create a block-level checkpoint > >functionality. You would have the primary device, which would continue to > >receive read and write requests after the checkpoint instantiation, and > >then the secondary device, where you would copy the original version of any > >sectors written to the primary device after the checkpoint. > > Hmm, that is the reverse of what I thought it should do, but I can > certainly see the point... I think doing it either way would be useful. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020128131834.A4983>