Skip to main content
A pool name is an API. Services, replication jobs, and inventory all address storage through it — so it must only encode things that never change. The performance tier never changes. Everything else does.

​
The convention

Three names, used identically on every node that has that tier of storage: A node only creates the pools it has hardware for. A proxmox-2-style node with an HDD array gets bulk; a node with spare flash gets fast; every ZFS-boot node already has rpool.

​
What a pool name must never encode

The test for a candidate name: does this fact survive a hardware change? Tier names survive all of those events. The name tells you the speed class; the dataset path below it tells you the purpose.

​
The payoff: identical paths everywhere

Because the pool name is the same on every node, a dataset’s full path is node-agnostic:
  • bulk/data means “the bulk media dataset” on whichever node currently holds it. Moving the service to another node changes zero mount configuration.
  • Replication targets line up by construction — bulk/data on the source replicates to bulk/replica/<source>/data on the destination, and a restored replica is byte-identical at the same path it had at home.
  • Inventory and IaC reference one path per dataset, not one per node × dataset.
Any node can stand in for another, because storage addressing was never node-specific to begin with.

​
What this connects to

ZFS backup & replication

The snapshot and replication layers that ride on these pools.

VMID & network tier model

The same encode-only-what-never-changes philosophy, applied to guest identity.

Homelab

The hardware behind the pools.