Date: Fri, 18 Dec 1998 13:14:34 +1030 From: Greg Lehey <grog@lemis.com> To: Matthew Patton <patton@sysnet.net>, Dan Swartzendruber <dswartz@druber.com> Cc: freebsd-isp@FreeBSD.ORG Subject: Re: RAID solutions? Message-ID: <19981218131434.M486@freebie.lemis.com> In-Reply-To: <l03110705b29e428c72d1@[192.168.1.10]>; from Matthew Patton on Thu, Dec 17, 1998 at 01:05:29AM -0500 References: <3.0.5.32.19981215231329.00966ae0@mail.kersur.net> <l03110705b29e428c72d1@[192.168.1.10]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, 17 December 1998 at 1:05:29 -0500, Matthew Patton wrote: > for a news spool you want SPEED, SPEED, and SPEED!! You do *NOT* want RAID5 > (it's damn slow on writes) and most definately NOT in software. Get a slew > of disks and use raid 10 (stripe + mirror) for utmost speed. Striping (``RAID 0'') will give you better speed for concurrent access, which is what you are talking about here. Mirroring (RAID-1) will give you better read performance, assuming your system balances reads across the mirror, but worse write performance. > Given modern disks, 4 on a channel will tend to saturate the > bus. Theoretical performance numbers will not be reached due to > firmware bugs in drives (common) or inefficient drivers. Correct. Consider also the extreme effect of latency in a multi-access system such as a news server. > Here are my suggestions, all are predominantly HW based. In all cases, 1 > hot spare per channel. Plenty of ambient cooling and power regulation is > needed. In addition to the simple 'art' of RAID selection there is also > 'slice/interleave' size to factor in. With drives doing full track read > aheads with their own fancy algorithms and varying lamounts of onboard > cache, precise numbers are very difficult to come up with. It depends on > what kinds of IO you do. On a database, I would probably use 16 or > 32kb. On FreeBSD, this is too small. > A media server (large files) 64kb or more. On boxes with lots of > small sizes, accessed randomly and rapidly, 8 or 16kb. Far too small > But you dont' want to fill up the controller's command queue with > too many commands. That's not the big problem. The fact is that the block I/O system issues requests of between .5kB and 60 kB; a typical mix is somewhere round 8 kB. You can't stop any striping system from breaking a request into two physical requests, and if you do it wrong it can be broken into several. This will result in a significant drop in performance: the decrease in transfer time per disk is offset by the order of magnitude greater increase in latency. With modern disk sizes and the FreeBSD block I/O system, you can expect to have a reasonably small number of fragmented requests with a stripe size between 256 kB and 512 kB; I can't see any reason not to increase the size to 2 or 4 MB on a large disk. The easiest way to consider the impact of any transfer is the total time it takes: since just about everything is cached, the time relationship between the request and its completion is not important. Consider, then, a typical news article of 24 kB, which will probably be read in a single I/O. Take disks with a transfer rate of 6 MB/s and an average positioning time of 8 ms, and a file system with 4 kB blocks. Since it's 24 kB, we don't have to worry about fragments, so the file will start on a 4 kB boundary. The number of transfers required depends on where the block starts: it's (S + F - 1) / S, where S is the stripe size in file system blocks, and F is the file size in file system blocks. 1: Stripe size of 4 kB. You'll have 6 transfers. Total subsystem load: 48 ms latency, 2 ms transfer, 50 ms total. 2: Stripe size of 8 kB. On average, you'll have 3.5 transfers. Total subsystem load: 28 ms latency, 2 ms transfer, 30 ms total. 3: Stripe size of 16 kB. On average, you'll have 2.25 transfers. Total subsystem load: 18 ms latency, 2 ms transfer, 20 ms total. 4: Stripe size of 256 kB. On average, you'll have 1.08 transfers. Total subsystem load: 8.6 ms latency, 2 ms transfer, 10.6 ms total. These calculations are borne out in practice. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981218131434.M486>