2008-09-12
ZFS's helpful attention to detail
Because I just ran into this:
Imagine that you have a ZFS pool, call it tank to match the convention
of ZFS examples, and that it has three spare devices configured. Further
imagine that you want to remove those three configured spares from the
pool:
# zpool remove tank c4t0d0 c4t0d1 c4t0d2
(No error messages are emitted.)
Then, because you are a cautious person (or because you have a tool
that automatically saves your pool configurations somewhere), you
actually examine the spares configuration for tank. Guess what
you will find?
You'll find that tank still has two spares. Silently, ZFS has only
removed the c4t0d0 spare disk.
Now, in theory this behavior is documented in the zpool manpage and
help, because the remove command is described as:
zpool remove pool vdev
Notice how that doesn't say you can specify more than one vdev. In the grand Unix tradition of informative manpages, this means that you can't.
Of course, it would be nice if ZFS's administrative commands actually gave an error message when you used them wrong, instead of just ignoring anything that wasn't supposed to be there. Ignoring things that you don't expect is not robust.
Why you want sysadmins, not users, to be providing the computing
One possible reaction to how we don't really control user desktops is to shrug and let users go their own way if they don't want to have one of the short list of provided desktop environments. You won't fight it, but you won't do anything to support it either; you'll let them run Ubuntu, or OS X, or whatever, but they're entirely on their own.
This is a great way to make a terrible mistake. You really do want 'IT' to be providing the computing environment, even if it means bending over backwards to support odd things, because the real job is to keep the organization working, or to put it another way, (part of) our real job is to keep the organization from getting harmed by IT issues.
(This 'real job' doesn't necessarily have anything to do with our official responsibilities. Consider it our speciality within the organization, if you want.)
If users build their computing environment themselves and do it badly, and it blows up, the organization still has a problem, possibly a bad one. And the more we wash our hands of environments, the less chances we have to mitigate potential disasters before they blow up in everyone's face. So over all the organization is best served if 'IT' provides the computing so that users don't have to try to do it themselves, and as we've seen that means trying to support things that the users like even if they don't entirely fit into our neat plans.
(I am not saying that users are always going to do build their computing environments badly. But I do think that they are predisposed to do so simply because it's not officially part of their job, so they don't get the time and resources to do the work. Overworking people is a recipe for problems in any field, and when something is not officially your job it has to take second place to your job's work.)
Disclaimer: this often doesn't work out in practice, but that's another entry.