My rep in congress (Scalable’s too) is pointing out some unhappy guestimates of how our local economy will fare: Well, while agree with him that its getting worse here (we blew through 14.1% in May … likely at 15% or worse now in July), had the autos fallen, the unemployment would have been worse. This said, it is very important to let the economy do what economies do best, and stop trying to pretend to control it.

* from the testing lab, some very fast #[hpc](http://search.twitter.com/search?q=%23hpc) #[storage](http://search.twitter.com/search?q=%23storage) systems: 24TB JR4 writes at 2 GB/s, 96 TB JR5 reads at 2.2 GB/s. [#](http://twitter.com/sijoe/statuses/2592997412) Powered by Twitter Tools.

The raid has finished building on the JackRabbit 5U (JR5) (these units are now available from us or our reseller partners in the US, EU, and India). As a refresher, this is the 96TB unit, with 3 RAID cards, and 48x 2TB enterprise SATA disks. The RAIDs are hardware RAID6 (16 drives, 1 hot spare and 15 RAID drives, yielding 13 data drives). 3 groups of 13x 2TB drives is 78TB.

Following Chris Samuel’s suggestion, I pulled down version 1.96 of bonnie and built it. The machine I am using now is a Scientific Linux based system, with Scalable Informatics 2.6.28.7 kernel. Scientific Linux is yet another RHEL rebuild. This is a customer requested distribution for this machine. SL suffers from the RHEL kernel, which is IMO inappropriate for use as a high performance storage system kernel. Workload patterns our customers wish to test regularly crash the RHEL distro kernels.

I started thinking about bonnie’s IO after looking at some of the numbers, and how the system behaved while running the tool. Fio is much better and more controllable tool. You can understand what it is doing. And you can use it to model bonnie, and therefore understand what bonnie is and isn’t doing. In short, while running bonnie++, I found the core machine stats, as seen in vmstat, dstat, iostat, and other tools, to be basically idle during the writes.

This is what our tagline of Simply Faster means. The performance is there, and is simple to use. See below. On DV4 root@dv4:~# mount -o intr,rsize=262144,wsize=262144,tcp 10.1.3.1:/data /data2 root@dv4:~# ls -alF /data2 total 67108868 drwxr-xr-x 2 root root 21 2009-07-10 11:01 ./ drwxr-xr-x 23 root root 4096 2009-07-10 17:18 ../ -rw-r--r-- 1 root root 68719476736 2009-07-10 13:07 big.file root@dv4:~# dd if=/data2/big.file of=/dev/null bs=16M 4096+0 records in 4096+0 records out 68719476736 bytes (69 GB) copied, 110.

The JR5 is still building its RAID. 96TB of sweetness in that unit. But its the JR4 that is tearing up the records. Did a little tuning, just to fix a problem with the OS drives. I’ll have a long diatribe on this at some point, but not now. JR4, sitting on the bench in the lab. Pair of Chelsio 10GbE cards, 8 cores of Nehalem goodness, 48 GB ram. Lets take her for a spin, and light up the afterburners.

In the late 80s, right before I finished undergraduate work at Stony Brook, I bought an orange colored 1973 Chevy Nova. It was, well, butt ugly. But it had a 350 small block engine in it which, as I had been told by people (supposedly) more knowledgeable than I (in these areas), was shared by the Corvette models of that year. I don’t know if that was true. I do know that this was an engine I could tune.

* Stabilizing JR4 with SAS drives. Some motherboard - raid issues to be dealt with. Performance is good. [#](http://twitter.com/sijoe/statuses/2517905215) * The 2TB drives have arrived ... the 2TB drives have arrived ... [#](http://twitter.com/sijoe/statuses/2517918749) Powered by Twitter Tools.

Thought a few people might like to see this. A new JackRabbit (JR4) being built. We are testing one of its RAIDs. Dealing with some MB issues, but otherwise, back onto stable ground. This is a single RAID card with 8 drives, 7 in a RAID6 + 1 hot spare. Large sequential streaming read and write. 4x larger than RAM in the machine. Caching is not relevant to this. No tuning.