Wandering Thoughts archives


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.

solaris/ZFSZpoolRemoveGotcha written at 12:06:17; Add Comment

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.

tech/WhyITComputing written at 02:02:37; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.