I have recently started thinking about the concept of what I will callthe 'error distance' of sysadmin commands: how much do you have tochange a perfectly normal command in order to do something undesirableor disastrous (instead of just failing with an error)?

(As an example, consider the ZFS command to expand a ZFS pool witha new pair of mirrored disks, which is ' zpool add POOL mirror DEV1DEV2 '. If you accidentally omit the ' mirror ', you will add twounmirrored

Suppose that you have a command with an unnervingly low error distance , either because a vendor stuck you with it orbecause it's the natural way to structure the command's arguments.The way to fix this is to change the sort of error required to makea mistake, so that you move from a likely change to an unlikely one.

(If you are working with a vendor command, you will need to do thiswith some sort of a cover script or program. If you are working witha

A while back I wrote about how I had discoveredthat ZFS could wind up doing excessive readahead when faced with manystreams of sequential read IO and wind up throwing 90% to 95% ofthe IO that it had done (with terrible consequences for applicationperformance). It's time for an update on that situation.

First, for various reasons we wound up moving to Solaris server machineswith 8 GB of memory (SunFire X2200s instead of X2100s)