/devices/pseudo/bitbucket@0:bitbucket: Musings from the bitbucket

In 1998 and 1999 I was a Solaris system administrator at one of Sydney's 5 universities. I was quite green --- this was my second sysadmin job --- and I'd been given the task of administering the University's Finance arm's server and the Uni's DR server. It was quite a challenge for me: each box was a SparcServer-1000 with about 30 attached disks. The DR host had those disks all nicely physically organised into an SSA-100 array whereas the Finance host had unipacks and multipacks crowded around it in a semi-neat fashion.

I had to learn VxVM (for the DR box) and SDS (for the Finance host) very quickly, and I realised that doing so from the command line perspective was very clearly the way to go.... in a disaster I wouldn't have a graphical head to let me look at the semi-pretty gui that VxVM 2.5 and SDS 4.1 required.

Working on the Finance box required close interaction with the Oracle DBAs that we had --- they'd frequently want to move Oracle datafiles around in order to maximise access speed .... whether that meant having the partition on the "fast" end of the disk or on a fast spindle or a faster scsi controller or on a lower scsi id. That was a pain. The DR box was another challenge because I had to somehow make the 30x4gb disks appear to be a single storage pool for whichever host had to be hosted there in a DR situation. Since we had three hosts which might get that experience it was a bit difficult. While all of them ran Oracle, they each ran different versions of Oracle, had different application filesystem requirements.... you get the idea I'm sure.

After a year working in that part of the Uni I moved to work for a smaller (30 people) group in the research division. It was great being top dog in the sysadmin group.... since I was their only sysadmin I migrated that group off a Novell NetWare server which quite seriously crashed every day. I got them onto an E250 running Solaris 2.6, Samba and PC-Netlink (for the Macs!) Once again I had to carefully carve up the internal disks and the luns from the attached A1000 (never, ever remove lun0 from an A1000 if you want it to work). I had to worry about quotas and how much space to allocate for the application I wrote for them and how much to allocate for sendmail spool files too. I recall that I ended up creating my filesystems (a) to not exceed the size I could ufsdump to a single DLT7000 tape (35gb), and (b) by grabbing the few megabytes at the end of what I figured were correctly sized filesystems and using an SDS concat to make somethng out of.

Hideous! Time-wasting! Ugly!

Oh, if only we'd had ZFS back then..... One of ZFS' main aims is to end the suffering of the humble (and not so humble!) system admin. With those hosts it would not have been difficult to add more storage or a new filesystem:

zfs add financepool mirror c9t0d0 c10t0d0

With the research group I wouldn't have had to worry about setting quotas for each filesystem by editing the quotatab and remembering to mount the filesystem with quotas turned on:

zfs set quota=1g research/home/louise

not only could I have done with some compression on those Oracle datafiles

zfs set compression=on finance

zfs set compression=on oracledata

but I could also have used zfs to send incremental backups of the relevant bits from the finance host to the DR box:

zfs backup -i finance/application@12:00 finance/application@12:01 | ssh DRbox zfs restore -d /finance/application

Do you get it? Do you understand why we've been desperately keen to get ZFS into your hands? Do you want to start making use of all this? It's quite fine with me (us?) if you want to keep using SVM and VxVM. Really, it is. When you're ready, please go and have a look at ZFS. Drop it onto a test machine and play with it. Look at the source code and the documentation and reach out to the possibilities of spending your time productively rather than in slicing up disks.