From owner-freebsd-hardware Tue Mar 3 17:44:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17338 for freebsd-hardware-outgoing; Tue, 3 Mar 1998 17:44:53 -0800 (PST) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero-fxp0.Simon-Shapiro.ORG [206.190.148.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA17211 for ; Tue, 3 Mar 1998 17:44:19 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 21428 invoked by uid 1000); 4 Mar 1998 01:50:55 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-021598 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19980303200705.12976@clifford.inch.com> Date: Tue, 03 Mar 1998 17:50:55 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Omar Thameen Subject: Re: getting oriented with RAID Cc: freebsd-hardware@FreeBSD.ORG Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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