Every pool on one screen.

Fly through your pools

Tap Super and every pool is a card: its layout, a light for each drive, how full it is and what it is doing. Super+Tab lays them out as a wall, imported pools lit and the ones it could import dim, the system's own among them. Enter goes into a pool, Space opens its menu: scrub, trim, clear, export, or import.

In front, a pool is its last second: reads and writes, the waits, the ARC's hits, what reached the log device, whether writes were held back, how long transaction groups took to sync, and verdicts, the worst first.

Every drive, by its serial

Each drive is named by its serial, with its model, size and place in the pool, its temperature and its hours, lit by its state and its SMART verdict. Its menu takes it offline, brings it back, or detaches it from a mirror. Long SMART tests run on a schedule per pool, a drive's test age read from its own power-on hours, and a sleeping drive is not woken to be read.

A disk that holds any part of a pool is never offered to a new one, imported or not. A new pool is made from a design in zpool's own words, and its verdict comes first: what it yields, how many disks it survives, and the warnings an experienced operator would give.

Snapshots that keep themselves

Every dataset is a card, and in front it shows every setting and where each one came from. A snapshot policy is one property, hourly=24,daily=7 say, kept by everything under it; pruning touches only the snapshots the policy made, never a held or a cloned one, and rollback is refused while newer snapshots stand.

A backup is a restore you tested

Replication sends what changed since the newest snapshot both sides hold, matched by its GUID, not its name, and a bookmark keeps the chain alive after the snapshot is pruned. A cut transfer resumes. An encrypted dataset goes raw, its key staying home, and the plan says so before a byte moves. Copies land read-only, unmounted, and marked as replicas.

Then the drill proves it: a canary is written at the source, snapshotted, carried to the archive, and read back from a read-only clone of the archive's copy. The clone goes, the result is an event, and either the chain works today or you know the step where it does not.

Nothing passes by not running

Every check has three outcomes: ok, failed, or did not run, and did not run counts as failed. The pools, the keys, the scrub and trim schedules, SMART, the share daemons, the replication rules and the UPS each say what they found, what they expected, and the command that puts it right.

What went wrong while nobody was looking is an event: a scrub that finished, a pool that degraded, a spare that stood in. Events are counted on the bar, listed in the Events window, and pushed to ntfy, Gotify, Discord or any JSON hook if you like.

Every second the pools were busy

Every ten seconds zxpd keeps one second of each pool: latency histograms whole, ZFS's own latency per dataset, the I/O each process made, the calls that were slow, and the kernel's log. SMART numbers, disk errors, scans and space are kept beside them. Two days in full, six weeks in five-minute steps.

Lightning fast, keyboard driven

The same storage in a terminal: pools, datasets, snapshots, disks, the overview, jobs and health, a tab each and a key for every verb, named in the line under them. On the box or over ssh.

Everything a pool needs

Things you will actually do

Real commands; the desktop does the same from its menus, and every change takes --dry-run.

Get one on your shelf

openssl pkeyutl -verify -pubin \
  -inkey release.pem -rawin \
  -in SHA256SUMS -sigfile SHA256SUMS.sig
sha256sum -c SHA256SUMS --ignore-missing

sudo dd if=zettarack-zxp-0.6.0.iso of=/dev/sdX \
  bs=4M status=progress conv=fsync