This is a new 24TB raw JackRabbit-M system we are burning in for a customer. Unit will ship in short order, but I thought you might like to see what happens when we take it for a spin. And when we crack the throttle. First the basics: 24x 1TB drives (SATA II nearline drives, not desktop units), 4U case. 2 hot spares, RAID6 (yes, these numbers are with RAID6). System has 16 GB RAM.

Expected lifetime (e.g. how long until a hacker pwnz it? or put another way, how long until you lose control of this ) windows system on the internet? 4 minutes.

This was fun. Well, ok, it wasn’t. But it works now. The ofa_kernel rpm crashes and burns being rebuilt on FC9. As do sdp, rds, ibutils, and dapl. Fine. Also have to downgrade tcl to 8.4 from 8.5. Because the RPMs hard-link to a specific library in tk (which depends upon tcl). Again, fine. Run the install.pl script. Select install. Select customize. Select everything but those things. Go get coffee. Note that the conversion to gcc 4.

Suppose you want to build a new kernel RPM that incorporates a different kernel (slightly up or down from distribution baseline). You want to turn off all their patches, and simply build the kernel, the headers, the -devel, … Can you do it? No I am serious… can you do it? The following is a bit of a rant. Borne out of frustration with things that are designed broken (IMO).

In reviewing a new rev of some product that competes with our JackRabbit unit, I noted that the new rev actually copies a number of the good ideas we have been using in our JackRabbits for quite a while. I am impressed :) I guess if you can’t beat em, join em.

Seagate just announced a 1.5 TB desktop drive, with the enterprise unit sure to follow. Delivery of desktop drives should be in August. If we used 48 of these in our 5U JackRabbit unit, we would be able to provide 72 TB raw. A rack full (8) would hit 576 TB raw, or nearly 0.6 PB/rack. FWIW: we have customers whom have requested the desktop drive variants. We see failure rates about the same as the enterprise/NL units.

We are in the midst of Solaris 10 testing for a customer. Explaining why Linux is so much faster (and more stable) on the hardware is getting old. So I’ll take a break and talk about the windows 200x experiences we had recently. A customer wanted to see performance on a number of things running on Windows 2003. They had a particular application that runs on it, and wanted to see what we could do with JackRabbit.

Another Solaris crash running bonnie++ during testing. I am convinced it is a driver issue, but before I go speaking to the people writing the driver, I want a good convincing stack trace to hand them (and a core file). I found the core files (shades of Irix past, I like the fact that I get them). Looked for SCAT (Solaris Crash Analysis Tool). 4.1 is out, for Sparc only. 5.

So we have Solaris 10 installed on a JackRabbit-M. According to Sun’s license, as I have learned last night, we cannot report benchmark results without permission from Sun. Sad, but this is how they wish to govern information flow around their product. Our rationale for testing was to finally get some numbers that we can provide to users/customers about real zfs performance. There is a huge amount of (largely uncontested) information (emanating mainly from Sun and its agents) that zfs is a very fast file system.

Hmmmmmmmmmm …. # /opt/csw/bin/iozone -Ra -n 16m -g 16g -y 16m -m -b sol10-jrm-large.xls Iozone: Performance Test of File I/O Version $Revision: 3.217 $ Compiled for 32 bit mode. Build: Solaris Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Jean-Marc Zucconi, Jeff Blomberg, Erik Habbinga, Kris Strecker. Run began: Wed Jul 2 18:47:07 2008 Excel chart generation enabled Auto Mode Using minimum file size of 16384 kilobytes.