Date: Mon, 13 Jul 1998 23:31:08 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gibbs@plutotech.com (Justin T. Gibbs) Cc: andre@pipeline.ch, gibbs@plutotech.com, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, FreeBSD-fs@FreeBSD.ORG Subject: Re: Software RAID Message-ID: <199807132331.QAA15175@usr08.primenet.com> In-Reply-To: <199807132219.QAA07976@pluto.plutotech.com> from "Justin T. Gibbs" at Jul 13, 98 04:14:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> There is supposedly some work being done in the NetBSD environment to > >> pull RaidFrame into their kernel. You may want to get involved with > >> that effort. > > > >Terry did that already for FreeBSD: http://www.freebsd.org/~terry > > Last I heard, Terry had ported the userland implementation to FreeBSD, > not the kernel one. This is correct. I did the userspace port, and I sent the patches back to the maintainer; in theory it should work "out of the box". Which begs the question: "who is going through all the ports and sending those patches back to the maintainers so FreeBSD is supported out of the box?". > The kernel stuff would actually give reasonable > performance since the userland code doesn't have "real threads" to rely > on. I think the value of quote-unquote "real threads" has been greatly exaggerated; kernel threads result in SMP scalability and higher context switch overhead and more interleaved I/O, and that's presuming something has been done about scheduler and processor affinity (I have yet to see John Dyson's patches for this committed, however, even though Elvind and other have copies). The biggest overhead in a software RAID 5 is the software instead of hardware checksum calculation, and that's going to be a much higher penalty than non-interleaved I/O (IMO; writes are typically interleaved, and where you care about reads, you will be set to trigger read-ahead). Software RAID is a data integrity issue, not a performance one, and I think making the performance argument for whatever reason (protection domain crossing, interleaved I/O, SMP scalability, etc.) is a strawman at best. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199807132331.QAA15175>