Date: Sun, 28 Jun 1998 16:29:02 +0930 From: Greg Lehey <grog@lemis.com> To: Richard Foulk <richard@pegasus.com>, FreeBSD Hackers <hackers@FreeBSD.ORG> Subject: Re: RAID and FreeBSD Message-ID: <19980628162902.B28872@freebie.lemis.com> In-Reply-To: <199806280531.TAA26134@pegasus.com>; from Richard Foulk on Sat, Jun 27, 1998 at 07:31:09PM -1000 References: <grog@lemis.com> <199806280531.TAA26134@pegasus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980628162902.B28872>