Date: Mon, 28 Jan 2002 11:15:14 -0700 From: "Kenneth D. Merry" <ken@kdm.org> To: Poul-Henning Kamp <phk@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: Geom project, limited preview... Message-ID: <20020128111514.A3819@panzer.kdm.org> In-Reply-To: <42006.1012230011@critter.freebsd.dk>; from phk@FreeBSD.ORG on Mon, Jan 28, 2002 at 04:00:11PM %2B0100 References: <42006.1012230011@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 28, 2002 at 16:00:11 +0100, Poul-Henning Kamp wrote: > > Ok, some of you have heard that the Geom project is now finally underway. > > You can get a brief (and old) idea what it is here: > > http://www.freebsd.org/~phk/Geom > > General access to the source will happen when the code is "ready to > do something" for the average machine, which said another way is > when BSD and MBR is working well enough to boot a random -current > machine, hopefully in less than a month. > > In the meantime I'll provide early access to people who have a > qualified interest in this code. (Send me email, leave your bikeshed > at home.) > > I will present the architecture in Geom and answer questions about it > in a timeslot assigned for it at the kernel summit at BSDcon. > > I'm interested in getting in touch with people who are interested in > writing modules for Geom or people who work new architectures and > have to contest strange disklabel formats -> get in touch with me. 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. - support for external parity engines for RAID-5 parity calculation. (If you do any sort of RAID-5 with this.) 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. This way, you could have a device checkpoint at a given time. It would be the opposite of your "COW" proposal, in that the secondary device gets a copy of the original data, instead of any writes to the primary device. This wouldn't be as nice as the FFS checkpoint functionality, but could be useful. (With filesystem checkpoints, you can more accurately guarantee filesystem consistency, and you can make use of space unused by the filesystem. With block device checkpoints, you have to have another device for temporary storage.) (The Adaptec 'aac' raid controllers have this sort of functionality, but it is currently only available under Windows.) 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?20020128111514.A3819>