Date: Thu, 19 Sep 1996 10:20:56 +0200 From: Stefan Grefen <grefen@carpe.net> To: FREEBSD-SCSI-L <freebsd-scsi@FreeBSD.org> Cc: FREEBSD-CURRENT-L <freebsd-current@FreeBSD.org>, FREEBSD-ISP-L <freebsd-isp@FreeBSD.org> Subject: Re: Streamlogic RAID array benchmarks Message-ID: <3409.843121256@hex.grefen.carpe.net> In-Reply-To: Brian Tao's message <Pine.NEB.3.92.960917173042.7033P-100000@zap.io.org> of Wed, 18 Sep 96 18:12:07 EDT. References: <Pine.NEB.3.92.960917173042.7033P-100000@zap.io.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.NEB.3.92.960917173042.7033P-100000@zap.io.org> Brian Tao wrote: [...] > > All the usual tools under FreeBSD treat the RAID as a single > drive. The default stripe size is 8K, RAID 5 (striping with parity). > This can be changed via the LCD keypad on the unit itself, or with a > VT-100 interface via the serial port. > > The tests were conducted on newly newfs'd filesystems. sd0 is the > single 4GB drive and sd1 is the RAID. A unit from CMD should be > arriving next week, so I'll have another product to benchmark. > Comments welcome, and please note the Reply-To. You see the benefits of a RAID array only if you access it with stripe-block size or multiple of it. Especially writes suffer from bad performance if you write fractions of a stripe-block (since it first has to read the the remainder of it or the parity block (or both) depending on implementation and where the fractional access occurred). This gives you a high latency which is results in poor performance at least for single-stream access. I assume from your statements that they use the 3 disks as "Data Data Parity" not as a 'true' RAID 5 "Data Data Data Data Parity" (this would have other side effects too). Assuming that 'stripe size is 8K' means that it has 4K blocks on each drive, Every request <8K is SLOW. (it can also mean 8k blocks on each drive which will demand 16k blocks, the phrase 'stripe size' is used different by different vendors). Some of the RAID drives can be configured to complete the SCSI operation when the block is in memory instead when it is commited to disk. This has the same effect as a disk write buffer (with the disadvanatge that it isn't written in case of a power failure). This can't be turned of on some CMD arrays (the recommend to only use it with an UPS). You need to newfs your filesystem to at least 8 (or 16k) blocksize in the default configuration. This ensures that the majority of writes are as fast as possible. If you have large files and writes you can go for even bigger blocksizes. If you have lots of small files reduce the RAID block to the minimum value and use smaller blocksizes. For 'normally' used filesystems a 1-1 mapping of stripe-blocks to filesystem blocks gives (on most systems) the best overall performance. (You have to balance bandwidth versus latency). On the other hand if the Seagate uses a write buffer and tagged queuing and the RAID doesn't it'll loose on any non purely sequential access. To figure out how fast the RAID can go just dd a huge file (/dev/zero) to and from the raw partition with different blocksizes. $ time dd if=/dev/zero of=/dev/rsd1a bs=4196 count=5120 # this will be SLOW $ time dd if=/dev/zero of=/dev/rsd1a bs=8192 count=10240 $ time dd if=/dev/zero of=/dev/rsd1a bs=16384 count=5120 ... Another good test is to talk to Arrays Cache (turn on every bit of performance switch you can find regardless of data-security) and write as above with the minmum possible request size to it. (512). This gives you the upper-limit on scsi-transaction the drives can handle on your bus. (don't be suprised if it maxes out at 500 (250 k) or so :-) )). Stefan > -- > Brian Tao (BT300, taob@io.org, taob@ican.net) > Senior Systems and Network Administrator, Internet Canada Corp. > "Though this be madness, yet there is method in't" > > -- Stefan Grefen Am Grossberg 16, 55130 Mainz, Germany grefen@carpe.net +49 6131 998566 Fax:+49 6131 998568 Living on Earth may be expensive, but it includes an annual free trip around the Sun.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3409.843121256>