From owner-freebsd-hackers Sat Jun 27 23:59:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA09255 for freebsd-hackers-outgoing; Sat, 27 Jun 1998 23:59:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA09249 for ; Sat, 27 Jun 1998 23:59:17 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id QAA28947; Sun, 28 Jun 1998 16:29:03 +0930 (CST) Message-ID: <19980628162902.B28872@freebie.lemis.com> Date: Sun, 28 Jun 1998 16:29:02 +0930 From: Greg Lehey To: Richard Foulk , FreeBSD Hackers Subject: Re: RAID and FreeBSD References: <199806280531.TAA26134@pegasus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199806280531.TAA26134@pegasus.com>; from Richard Foulk on Sat, Jun 27, 1998 at 07:31:09PM -1000 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd appreciate me if you'd address your replies to me as well as to the list. I'm also following up to -hackers, since this isn't really a hardware issue. On Saturday, 27 June 1998 at 19:31:09 -1000, Richard Foulk wrote: >>> Even if you upgrade your RAID box (which happens much less often than >>> OS upgrades in my experience), the system is simpler >> >> That's a valid point. >> >>> and the RAID is much more likely to be just like the vendors units. >> >> I don't understand that. What are you saying? > > Software RAID, implemented as a device driver, is an integral part of > the OS kernel. The kernel is a large collection of device drivers and > tools for accessing hardware. With Unix that collection is different on > just about every host that runs it -- due to so many different hardware > configurations. Sure. What is the relevance? >>> With OS-based software RAID you'll almost never have a configuration >>> just like the vendor's. >> >> I still don't understand. Are you saying that configurability is a >> disadvantage? > > No. Complexity is a disadvantage. I still don't understand your original statement, then: > Even if you upgrade your RAID box (which happens much less often > than OS upgrades in my experience), the system is simpler and the > RAID is much more likely to be just like the vendors units. continuing, > I look at RAID as a large repository for treasures that are collected > over time. The host system is the toolset used to mine those treasures. > The toolset is constantly being revised and updated as we devise better > ways to manipulate the data. > > Though the data on the RAID is probably being revised and updated too, > the means of storing it probably isn't. > > RAID is a powerful way of scattering large amounts of bits among a > collection of disks. It raises my comfort level to be able to say that > that complex system has been working reliably (unchanged) for so many > months and I have reason to expect that it will continue doing so. No disagreement so far. > Unix is a fabulous operating system that does many things quite well. > One of it's shortcomings is that the kernel is usually one large > monolithic program which combines all of it's device drivers together > in the same address space. > > Any driver is free to scribble in the code or data of any other. True, but in practice this almost never happens. Kernel problems are usually much more subtle than that. > So unlike a hardware RAID which is relatively simple and well-tested > in comparison. This is an assertion that isn't necessarily true. We've seen plenty of bad controller code around. > The various Unix device drivers that one implementation brings into > play may not even have been used together before. Sure, but that's not a problem. > Being of widely varying pedigree, maturity and level of testing, any > one of these drivers is free to modify the guts of the software RAID > engine directly. I've been around UNIX for a long time, but I can't ever recall this kind of bug. You're really implying accidental modification of the text, which would almost never leave functional code behind. > Free to change the way the mass data spew amplifier (RAID) throws it's > data around. When it's working correctly the RAID spreads data among > it's drives pretty wildly. > > Change a bit or two in one of it's algorithms and look out! > > If the driver or associated hardware for your video, keyboard, mouse, > cd-rom, sound-card or printer malfunctions you fix it and go back to work. > > If your RAID fails, some of your hard-won treasure may be lost forever. True, depending on how it fails. I think your model of the UNIX is kernel is a little simplistic. The kind of bugs you describe are relatively rare. There are two kinds of bugs that can afflict software RAID: 1. Plain ordinary software bugs within the driver. These are particularly insidious because they're the main source of data corruption. Obviously, these can affect hardware RAID as well. The only difference is that the UNIX environment usually has better testing tools than most standalone boxes, and if a bug occurs, it's easier to fix it in a system which allows rebuilding the software easily. 2. Problems which stem from the interaction of different drivers, such as you describe above. These are absent in hardware solutions, of course. They're also very rare in FreeBSD, and when they do occur, they almost never cause data corruption. Recall also that you still have a disk driver when accessing a RAID box. The only difference is where a specific subset of the disk access logic is located. In summary, I don't think that you can infer that software solutions are less reliable than hardware solutions. My expectation was that the main advantage of a hardware RAID solution would be the improved performance, but you deny this. Let's see if the change of mailing list gets some other viewpoints. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message