Date: Tue, 03 Mar 1998 17:50:55 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Omar Thameen <omar@clifford.inch.com> Cc: freebsd-hardware@FreeBSD.ORG Subject: Re: getting oriented with RAID Message-ID: <XFMail.980303175055.shimon@simon-shapiro.org> In-Reply-To: <19980303200705.12976@clifford.inch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04-Mar-98 Omar Thameen wrote:
...
> I really want to make sure I understand the implementation of RAID
> on freebsd, because it looks like a great thing to have on production
> servers. Sorry if this continues to be very basic.
Don't apologize. We all had to learn all that we know.
> First say I have a total of four 2G drives. I want to mirror them for
> redundancy, so I have 2x2G available space (I guess they would be
> called /dev/dpt0 and /dev/dpt1). Now say I want to optimize
> reads and writes, so I use ccd and make the 2x2G (mirrored) drives into
> one 4G drive, /dev/ccd0. If one of the mirrored drives goes bad,
> am I then able to power down the machine, replace the bad drive,
> then have the dpt manager perform its magic to recreate the data?
> Is ccd none the wiser?
Minor revisions:
a. You could have gone with RAID-5 and end up with 6GB usable
space, the same READ performance, lesser WITE perfromance and better CPU
utilization, but we will go with your example as it is more interesting.
b. The devices will not be called /dev/dptX, bust /dev/sdX. the DPT
hardware/firmware builds an array and maintains it. But it presents it
to the O/S as a ``disk''. For example, you have two Seagate ST5566778
drives, arranged in a RAID-1. the DPT knows about the seagates, but
not the BIOS, nor Unix. To them , it looks as a model ``You Can Change
It" disk made by vendor DPT. In the driver I have hooks that allow me
to ask the DPT to tell the truth, but these are not exported anywhere
(not even in the source I release).
c. Yes, neither the CCD, nor the Unix kernel can tell that the array is
running in degraded mode (a failed) drive. You will be able to tell
because the DPT will beep on every I/O to the degraded array
(``drive'')) and things will be a bit slower once you replace the
deffctive drive.
d. If you have a proper disk bay, you do not need to power down anything.
Just replace the drive with the fault light on. In this case, the new
drive will start rebuilding as soon as it is found (by the DPT) to be
good.
e. If you had a drive already in the system, designated a ``Hot Spare'',
it will go into service immediately. The new drive (replacing the
deffective) will become the new Hot Spare - Automatically.
f. Unix is NOT aware of ANY of this. As far as the kernel is concerned,
nothing bad happened, and nothing good happened. I will release tools
that will allow you to see, from a user program, these events. But
that is only so you can see and enjoy. You can also do useful things,
like shutting off the alarm :-)
> Second, I see that the "Entry Level" DPT RAID controllers run on
> a 68000 processor, while the "High Performance" ones use a 68040.
> In what types of applications does this become a factor? In the
> above system, I'm talking about a heavily hit pop3 or web server.
If you can afford it, get the PM3334UW. If not compromise with reality.
DPT have, on their web page, some guidelines. It all translates to number
of disk I/O ops/Sec. The PM3334UW can perfrom, with FreeBSD driving it to
SMALL (4k) blocks, better than 1,700 disk I/O per second. An entry level
board will do one third (?). Also, the latency will increase with
reduction in board cost. Last, but not least, the PM3334UDW is capable of
running three SCSI busses, all from one board, and one bracket in the back.
These will be differential interfaces, which allow you to run up to 75
feet of cable fron your Ultra (20MHz) Wide devices. Normal (Single Ended)
SCSI, at these operating parameters will start erring at about 10 feet of
cable.
Now, you are going to get a flood of ``Not, so, my controller does...''.
So, these are my opinions, and opinions only.
----------
Sincerely Yours,
Simon Shapiro
Shimon@Simon-Shapiro.ORG Voice: 503.799.2313
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980303175055.shimon>