In praise of zpool history

December 20, 2016

When I started out with ZFS, many years ago, I mostly ignored the existence of 'zpool history' and the information it can give you. Sure, it seemed like a neat side feature and I didn't exactly object to it, but I didn't think I'd ever use it for anything much. As it turns out, I was kind of wrong about that. I still don't use zpool history very often and it is not an essential part of what we do with ZFS, but it's turned out to be quite handy to have its information, especially over the long term. So what's it good for?

At the short term 'tactical' level, 'zpool history' will tell you for sure what you, someone else, or some automated system just did to your pool. Do you need to reconstruct a relatively exact sequence of commands so you can see how those two disks wound up as spares in some pool? You can. Did something go funny and now you're not totally sure what commands you issued to the pool? 'zpool history' will tell you.

At the long term 'strategic' level, 'zpool history' will let you track things you've done to your pool over time. For instance, it will tell you when a pool was created, when you added and removed an L2ARC device or a ZIL device, or when you grew the pool's vdevs. You can also look back to track problems and work you had to do; 'zpool history' will tell you every time you cleared errors on a pool device (or the entire pool), every spare activation, and every disk replacement. Sure, ideally you would keep track of this information outside of ZFS as well, but the world is not necessarily an ideal place. If nothing else, 'zpool history' is a backup to your other record keeping and thus serves as a second source of truth.

These things that 'zpool history' can do for you don't come up right away. You may never need to look back at the immediate past to see just what happened to a pool, and long term pool history only becomes interesting once your pools actually have been around for a fair while. But we now have pools that are several years old and I'm happy that I can look back at pretty much every pool-level thing we've done to them over their lifespan.

Of course 'zpool history' is not perfect because there's plenty of information it doesn't capture. It'll tell you when you added a L2ARC device but by itself it won't tell you how big that device was, and more to the point it'll tell you when you cleared error counts on a pool device but it won't tell you what the error counts were. And it doesn't record fault events and other things like that, just ZFS commands. But all by itself it's definitely useful and I'm glad that ZFS has it.

(I'm not going to complain about 'zpool history' recording all ZFS commands, although it does get a little painful if you have a pool that you snapshot a lot. You can always filter the output, and it's better to have the information than not have it.)


Comments on this page:

By liam at unc edu at 2016-12-20 09:34:47:

I suspect that the fault history was expected to be held in Solaris Fault Manager, so no need to clutter up zfs with it.

Written on 20 December 2016.
« Don't assume you can renew TLS certificates whenever you want to
An important little detail of our ZFS spares setup »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Dec 20 00:35:05 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.