I didn’t really go into much detail as to the content of the demo in my first (quick) post, so I’ll attempt to do that here. For those who want to see the demo in all its glory, the recordings can now be found on the Demos section of my ambassador web page, along with details of our upcoming demos.
Despite the usual British weather, our first tech. demo went well. We had a good attendance from more than thirty students and staff, which eased our worries about whether our message was getting through. Paul Humphreys opened the session with a short introduction to Sun entitled ‘A Hitchhiker’s Guide to Sun’. Paul showcased many of Sun’s products, including the ubiquitous Java platform, OpenSolaris and an array of Sun hardware including the SunRay technology (which we will feature in a future demo), the open SPARC chip and the ‘Thumper’ (a 48 terabyte storage solution). He also brought along a Sun Fire server containing one of the new Niagara 2 chips, which he opened up and showed to the assembled audience. There were quite a few comments about the lower heat output of the SPARC chip as compared with the consumer x86 and x86_64 chips, which need much more space for heatsinks and fans to keep the chip cool.
Paul then introduced the audience to Jarod Nash, who gave the main presentation of the day on ZFS. He explained how this integrates volume management into the filesystem, allowing individual mountpoints to have a dynamic size allocation. This solves the common problem of a mountpoint, such as /usr, running out of space, when there is still space available on /. With the usual situation where the filesystem is unaware of the volume management underneath, the data would have to be backed up and the filesystems resized. With ZFS, the allocation of space from the pool can simply be shifted. This also allows quota management to be integrated into the system.
The central feature of ZFS is its use of Copy-On-Write (COW) and checksums. In the past, checksumming every operation was thought to be too expensive, but these days the costs is negligible with the speed of current machines. The ZFS approach is to check every operation and ensure that the checksums remain consistent, which basically comes down to not trusting the hardware at all. Jarod explained that while other filesystems can catch bad blocks, there are all sorts of other issues that are missed, usually because something occurs silently in the past and then only shows up later (possibly much later) when the data is corrupt. This can include the disk simply throwing away data, an error in the transmission between main memory and the disk causing the data that is written to be corrupt, or the head of the disk simply landing in the wrong place and writing over some other data. ZFS can catch these errors, and, with mirroring, repair them. Jarod explained that mirroring is essential in avoiding data corruption, as otherwise ZFS has no way to obtain good data to repair these errors. ZFS takes a different approach to mirroring, due to its integration with the filesystem. If an error occurs on one of the disks, ZFS can catch it early, get the good data from the mirror, and then write the correct data back to the erroneous disk as well as sending it upwards to the kernel.
The use of COW means that there is no need for fsck with ZFS. While other filesystems attempt to simply recovery by making an atomic commit to a journal which can then be replayed by fsck, ZFS simply does all writes atomically, ensuring that the filesystem is never in a bad state that fsck would need to recover from. This is achieved by creating a copy of the data, altering that data, and then only pointing to that data when the new version is in place. Thus, if something fails while the copy is being made and written to, the filesystem will still point to the original data, avoiding a corrupted intermediate state.
Jarod closed the session with a live demo of ZFS. Using two USB disks, with a 100mb partition on each, he demonstrated how they could be assigned to a ZFS pool. He then copied data to the pool (the contents of /usr/include) and then filled one of the devices with zeros using dd. By invoking zfs scrub, he showed how ZFS found the bad disk and degraded it. He recovered from this by removing the bad disk from the pool, and then readding it. When readded, ZFS simply assumed it was empty and filled it with good data.
On leaving the demo, students were invited to take OpenSolaris CDs and books. The CDs turned out to be so popular that we ran out, despite Jarod having brought several copies of Developer Preview 2 in addition to our existing OpenSolaris starter packs. Further CDs are on order. The main question that came up post-session was on finding appropriate hardware to run OpenSolaris. Driver support is still not all it could be (Intel and NForce chipsets tend to be best on x86/x86_64), and students were recommended to consult the Hardware Compatability List (HCL) and the OpenSolaris forums.