Date: Tue, 3 Mar 1998 19:43:00 -0600 From: Karl Denninger <karl@mcs.net> To: shimon@simon-shapiro.org Cc: hackers@FreeBSD.ORG, Julian Elischer <julian@whistle.com>, Wilko Bulte <wilko@yedi.iaf.nl> Subject: Re: SCSI Bus redundancy... Message-ID: <19980303194300.45312@mcs.net> In-Reply-To: <XFMail.980303165721.shimon@simon-shapiro.org>; from Simon Shapiro on Tue, Mar 03, 1998 at 04:57:21PM -0800 References: <19980303180959.19173@mcs.net> <XFMail.980303165721.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 03, 1998 at 04:57:21PM -0800, Simon Shapiro wrote: > > This is one of the reasons I like the CMD RAID controllers. They have a > > nice big cache on them (with appropriate SIMMs), but they ALSO have an > > input for a 6V gelcel battery, and an internal *charging circuit* to > > manage it. > > Question is; Do they actually know how to do something useful with that > cache? Or is the reset that comes from the BIOS wipe them clean? Before > you answer, try it. I have seen batteries on computers before. They do > not always do what you think they should. Yes, they do, and yes, I've tried it. You can tell the controller to: 1) IGNORE a host-based RESET. 2) PASS a host-based reset through to the OTHER host ports (this is nice to tell a host that has "taken over" that you're back, and makes clustering possible in-band on the SCSI bus!) If you do this you'll abort any pending I/O from the other host channel(s) when the first RESET comes through. In either case the controller will start flushing any dirty pages to disk after about 30 seconds of inactivity. When you power down, IF you do so cleanly (ie: you tell the controller you're shutting down either from the front panel or via the control port - it has an RS232 interface) it disconnects the battery and the cache RAM (and event log) is lost. If you *DON'T* tell it first, it leaves the battery powering the refresh and the RAM contents remain. On reapplication of power the controller then verifies the array and immediately flushes any dirty pages out to the appropriate disk(s). You can manually disconnect the battery in this event from the front panel, but if the LED is blinking you have dirty buffers in there and it's a REALLY bad idea to push the button. :-) The cache is dual-mode; it functions as both a write-back cache and as a read cache. The controller does lazy-write aggregation (to avoid having to read/compute/write the RAID parity) when possible, but will flush the cache the hard way if it must. You can set the threshold for flushing to begin anywhere you want; it defaults to 50% full, but some Unix systems (FreeBSD included) seems to like it at 10% better. CMD tells me that Suns like this setting as well, but they're not quite sure why. If you want you can tell the controller not to use write-back (but to write-through instead); this is safer if you don't have a UPS or battery, of course, but is such a huge lose on RAID 5 writes that the battery and UPS are better options. Parity is computed in hardware by a dedicated proprietary chipset. You can also tell the controller to either: 1) Do no read-ahead (usually best for Unix, but not always; let the kernel handle that stuff) 2) Read ahead up to one raid block group (usually either 128 or 256 blocks), or less if you want (in reasonable increments). For sequentially-stored files, this can be a big win, but it comes at the cost of expending some of the cache (and rotational time) on possibly unused data. This thing has a 40Mhz MIPS processor on it, and pretty nice firmware along with an LCD front panel... > > In addition, they have inputs on them to sense UPS health (if you have > > one). > > > > You therefore get three levels of protection: > > > > 1) If the UPS goes onto battery, the unit starts "watching" things. > > > > 2) If it gets a low power warnings (ie: the "2 minute warning") > > it flushes the cache and goes into write-through mode. Now > > you're "safe" if you get screwed. > > > > 3) If you get dumped without warning, the battery is there and it will > > pick up the pieces when power returns. > > > > Note that if you have no battery connected or its discharged (the > > controller > > is smart enough to know), getting a 2-minute warning flushes the cache > > and > > quiesces the controller IMMEDIATELY. > > > > These controllers will not operate without either a battery or UPS, and > > both are (of course) preferred. > > That's the way I like it. Except, if the O/S is not in the loop, it may do > stupid things. Well, that much is true. You *CAN* lie about the UPS connection (ie: tell it you have one when you really don't) but that is DUMB DUMB DUMB. In that situation if you lose power the cache contents are toast and your disk structure may be as well. These beasties have 4 Ultra/Wide SCSI connections on them, and up to three can be designated for either host or drives (you must obviously have one of each). There are both Single-ended and differential versions available. I typically run them with one host connection and the drives split between two of the other busses; 5 9G disks with one warm spare, or for very high-volume writes, 6 9G disks in a RAID 0+1 config. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex support on ALL modems Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost 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?19980303194300.45312>