Date: Mon, 12 Jan 2004 13:45:21 +0100 From: Pawel Jakub Dawidek <nick@garage.freebsd.pl> To: Miguel Mendez <flynn@energyhq.es.eu.org> Cc: current@freebsd.org Subject: Re: Future of RAIDFrame Message-ID: <20040112124521.GE74246@garage.freebsd.pl> In-Reply-To: <400135EA.8050603@energyhq.es.eu.org> References: <40007D14.6090205@freebsd.org> <400135EA.8050603@energyhq.es.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--kHRd/tpU31Zn62xO Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 11, 2004 at 12:39:22PM +0100, Miguel Mendez wrote: +> >I started RAIDframe three years ago with the hope of bringing a proven +> >and extensible RAID stack to FreeBSD. Unfortunately, while it was made +> >to work pretty well on 4.x, it has never been viable on 5.x; it never +> >survived the introduction of GEOM and removal of the old disk layer. +> >I'm coming to the conclusion that I really don't have the time to work +> >on it in my spare time. Also, I've seen next to zero interest in it +> >from others, except for the occasional reminder that it doesn't work. +>=20 +> William Carrel used to maintain a set of patches for RAIDframe on 4.x,= =20 +> were they ever committed? No? Why not? +>=20 +> WRT lack of interest in RF. First, the 5.0 patches were horrible. That= =20 +> code was a mess to work with. Second, inertia. Most people with simple= =20 +> needs like mirroring and/or simple stripes were happy with good old=20 +> ccd(4). Those who needed a full volume manager (which neither ccd nor RF= =20 +> claim to be) used vinum. People with VxVM experience feel at home with= =20 +> it. Unfortunately, vinum has its own set of issues as well. +>=20 +> It's probably easier to write a set of GEOM classes from scratch than=20 +> trying to shoehorn RF into GEOM. And that's what I'm doing. I'm working on one geom class (called for now geom_raid) which will support transformations like: concatenation, stripe (raid0), mirror (raid1), raid4 and raid5. The main goal is to prepare driver-independent configuration description that will fit to as many existing ondisk metadata formats as possible. So on one axis we got transformations and on another we got different types of on-disk metadata formats. Work is going forward, but slow, because of leak of time of course. For now I got concatenation and stripe working and I'm sitting on raid5 implementation right now. I know now that after raid5 will be implemented I'll have raid4 working as well (it fits to raid5 description). Last step (in transformations) will be raid1. It will be great if RF could be fixed and I'm still wondering to help with it or just focus on my geom_raid. RF implementation is complex and it will take some time to well understand it in first way. Reverse-engineering is time-consuming. I'm opened for suggestions. If Scott is sure and determined to reanimate RF and help me to understand RF I think I can help. --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --kHRd/tpU31Zn62xO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBQAKW4T/PhmMH/Mf1AQFhrgQAmPYmLOwu+daWoZUbhn6+GQAuucy3+0I2 NeC2Diqk3RB5NngNsyTYEYbu/GLp+qJOBY3DpxhQD311XnxdDmBo/tf6pFHs9S5t DwfezHdWSgO+edSpbLt+xx6S4yJxtuY/SDOIIltzrXzioL6kpGy2vJKc6eWq6ni/ BIObyehDzKI= =sxPT -----END PGP SIGNATURE----- --kHRd/tpU31Zn62xO--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040112124521.GE74246>