We’ve been doing a lot of ZFS work around here lately, partially motivated by a sick (but not failed!) zpool after a power failure, partially motivated by some experimentation with an eye to what our next generation SmartOS environment is going to look like.
At this point it’s probably useful to dump out my personal set of ZFS bookmarks / reading list items.
There is no specific order. They’re all worth a looksee.
Six Metrics for Measuring ZFS Pool Performance from ixsystems:
Aaron Toponce’s ZFS Administration
Circa 2012 overview of ZFS and Zpool administration. Assumes ZFS on Linux (Debian), but that’s a very small part of the whole picture; most of the information given here is cross platform.
- (Local PDF mirror - ZPool Administration)
- (Local PDF mirror - ZFS Administration)
- (Local PDF mirror - Appendices)
TL;DR - it’s probably not worth it to dedupe. The economics barely worked in 2011.
TL;DR - it’s almost certainly worth it to turn on ZFS compression. Algorithm of choice is a matter for research for a particular dataset and CPU combination. Protip: Maildir format email stores are crunchy AF.
Slow zpool scrub
TL;DR - zpool scrub is aggressively non-interfering and backs off so as to not get in the way of more important traffic. This is usually the right thing to do, and zpool scrubs that take forever to finish are understandable in the context of other disk activity. Occastionally it’s not the right thing though. More on the ecosystem here.
Deleting Files on a Full Filesystem
Any Copy-On-Write filesystem that is 100.0000000000% full (no free space whatsoever) creates an interesting chicken-or-egg problem when trying to delete a file since there’s no place to put the updated metadata before you free the blocks that the file was occupying. Here are some hints.