Courtesy of a recent entry , I wasreading over my dotfiles when I stumbled over a remnant of a ratherpeculiar and annoying Unix (unfortunately, I no longer remember whichone it was). This Unix was notable for a simple reason: it didn't havea test program.

You might sensibly ask how on earth anything that can possibly callitself a Unix would be missing such a basic thing; after all, without test a lot of scripts don't work at all, since test is also known

Given the downsides covered in yesterday's entry , ZFS's decision to stripe data blocks acrossall of the disks in a raidz probably sounds rather odd. However, itactually is a sensible decision given ZFS's overall design goals. Theeasiest way to see why is to contemplate the problems posed by analternate design.

Suppose that ZFS did not turn a single data block into a 'paritystripe', but instead had the idea of what I will call a 'block set',a group of

Sun's ZFS contains a performance surprise for people using its versionof RAID-5 and RAID-6, which ZFS calls raidz and raidz2. To understandwhat is going on, it is necessary to start with some basic ZFS ideas.

One of the things that ZFS is worried about is disk corruption . To deal with this, ZFS famously checksums everythingthat it writes (both filesystem metadata and file data) and thenverifies that checksum when you read the things back; specifically,ZFS computes and checks a