Allow me to hoist my suspenders and stroke my scruffy gray beard for a few moments…
I’ve been a Solaris user for a long time now. I started with SunOS 4.1.3 in college, hacked on a Solaris 2.5.1-based proxy firewall (ANS InterLock, w00t!) for a few years, helped get that product working on Solaris 7, and then ended up at Sun Microsystems during the development of Solaris 9 and 10. On my own time I began working on Linux, as it matured and Solaris’ future became dim. And now, at Mozilla, I’m happy with OS X (aka unix with a sensible interface).
But more recently, I’ve had a Solaris itch growing. Solaris x86 — once the unloved bastard step-child — has clung to life through some rough times, and today is an entirely usable desktop OS. Kudos to the folks who have made it compatible with lots of hardware and Linux apps. My return to Solaris has had a few false starts, though… I struggled to get it working under Parallels (on OS X) last year before losing interest, then got it working on a spare PC until the dying video card made is unbearable. Then when Fred finished his internship at Mozilla, I swiped his PC and scrounged some spare parts to get a respectable system built. [Dual Xeon @ 2.2 Ghz, 1 GB RAM].
One reason I’ve been interested in Solaris again is that they’ve got some really spiffy technologies, some of which should be appearing in the next OS X release as well. Most prominently: ZFS and DTrace.
I’ve already got ZFS working on my “new” box… What a joy! If only the rest of Unix was this slick to use. Here’s what I did:
1. Dug though a box of old hard drives, and found 3 old-but-serviceable 9.1GB drives. Tossed into case, hooked up cables, and booted.
2. Created a ZFS storage pool named “build”:
# zpool create build raidz c0t2d0 c0t4d0 c0t8d0 # zpool status -v build pool: build state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM build ONLINE 0 0 0 raidz1 ONLINE 0 0 0 c0t2d0 ONLINE 0 0 0 c0t4d0 ONLINE 0 0 0 c0t8d0 ONLINE 0 0 0 errors: No known data errors
3. Not strictly needed; but created a ZFS filesystem in the pool for Firefox builds, and mounted it in a convenient place…
# zfs create build/firefox # zfs set mountpount=/export/home/dolske/ff build/firefox # zfs list NAME USED AVAIL REFER MOUNTPOINT blob 88.7M 60.9G 24.5K /blob blob/home 88.6M 60.9G 88.6M /export/home build 1.92G 14.6G 32.6K /build build/firefox 1.92G 14.6G 1.92G /export/home/dolske/ff
And that’s it! As far as command line based filesystem administration goes, that’s dead sexy. No formatting or partitioning needed. Just a few simple commands, and I’ve got a fast filesystem that’s striping across 3 devices, fault-tolerant, with error detection and correction. And that’s just the beginning of what ZFS can do.
You can also get some nice stats as the pool in use… Here I’m starting a build, with stats dumped every 15 seconds:
# zpool iostat build 15 capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- build 821M 24.4G 0 0 0 0 build 821M 24.4G 5 0 70.0K 8.53K build 821M 24.4G 1 28 35.4K 128K build 824M 24.4G 57 149 148K 181K build 827M 24.4G 90 147 182K 227K build 828M 24.4G 31 43 188K 211K build 839M 24.4G 16 38 115K 663K
I’m not really maxing out the drives during a build, but it’s fun to watch. The surprisingly-readable ZFS Administration Guide has more info on what goodies ZFS provides.