Pools

The Pools page lists the ZFS pools that Sylve manages. Select a pool or an expandable device row to reveal the actions that apply to it. Sylve can create pools from an unused raw disk or from unused partitions. It also creates its managed dataset layout after a pool is created.

Add an existing pool to Sylve

Sylve manages a pool only when you selected it during node initialization, created it from this page, or explicitly added it afterward. An existing ZFS pool is not automatically adopted merely because it is imported on the node.

To add an existing pool, go to Settings → System → Services, edit ZFS Pools, then select the imported pool that Sylve should manage and save the change. This is a deliberate authorization step: only add pools that you intend Sylve to use for its managed datasets, workloads, and storage features.

Why explicit selection is required

Nodes can have imported pools that belong to another application, an existing workload, or an administrator’s separate storage plan. Sylve does not select those pools by default, so it cannot create managed datasets or otherwise affect them accidentally. Select a pool only after you have confirmed that it is intended for Sylve management.

Before you create a pool

Caution

Creating, replacing, detaching, or deleting a pool changes real storage. Confirm the device names and their current usage in Storage → Disks before continuing.

Sylve offers only disks and partitions that are eligible for use:

Source	Eligible when	Not shown when
Raw disk	The disk is unused and does not have a GPT partition table.	It is already in use, already partitioned, or assigned to a pool.
Partition	The parent disk is partitioned, the disk has no EFI partition, and the partition is not already used by a pool.	The parent disk contains an EFI partition or the partition is already assigned.

A VDEV is a group of devices that ZFS treats as one storage unit. A pool must have at least one Data VDEV. The layout of the Data VDEVs determines the pool’s capacity and failure tolerance. Adding a cache, log, special, or dedup VDEV does not make an unprotected Data VDEV redundant.

Create a simple raw-disk pool

This first example uses the one free raw disk on the demo node to create a stripe pool. A one-device stripe is useful for a disposable test pool, but it has no redundancy. If the disk fails, the pool is lost.

1. Go to Storage → ZFS → Pools and select New.
2. Enter an alphanumeric pool name between 1 and 24 characters, such as labstripe.
3. Leave the initial VDEV as Data and Stripe.
4. Drag the available raw disk into the VDEV, or use the arrow on the disk card to add it to the last VDEV.
5. Confirm the usable capacity, then select Create.

After creation, the pool appears in the table with its capacity, allocation, health, and redundancy. Expand the pool row to inspect its Data VDEV and device.

VDEV types and redundancy

The Devices tab lets you add VDEVs and select their type. The available redundancy choices depend on the type and the number of devices in that VDEV.

VDEV type	Purpose	Redundancy choices in Sylve	Important consideration
Data	Stores ordinary pool data. At least one is required.	Stripe, Mirror, RAIDZ, RAIDZ2, RAIDZ3.	This is the pool’s primary capacity and protection layout. All Data VDEVs should use the same RAID type unless you deliberately enable Force Create.
Log (ZIL)	Serves synchronous write intent log workloads.	Stripe or Mirror.	A separate log VDEV is workload-specific. Use a mirror for fault tolerance.
Cache (L2ARC)	Provides a secondary read cache.	Stripe only.	It does not add redundancy or increase usable pool capacity.
Special	Holds special allocation classes, including metadata when configured by ZFS.	Stripe, Mirror, RAIDZ, RAIDZ2, RAIDZ3.	Loss of a special VDEV can make the pool unusable. Use a redundant layout in production.
Dedup	Holds deduplication table data when ZFS deduplication is used.	Stripe, Mirror, RAIDZ, RAIDZ2, RAIDZ3.	This is an advanced and memory-sensitive feature. Use redundant, suitable devices before enabling deduplication.
Spare	Stands by for replacement of a failed device.	Added separately, not as a VDEV.	A spare must be at least as large as the largest device in the pool.

Sylve enables a layout only when it has enough devices: Stripe needs 1, Mirror needs 2, RAIDZ needs 3, RAIDZ2 needs 4, and RAIDZ3 needs 5. Capacity is limited by the smallest device in a mirror or RAIDZ group, so use equal-sized devices within each VDEV.

Complex partition layout for the demo

After documenting the raw-disk example, you can reuse that demo disk for a topology walkthrough. First delete the disposable labstripe pool, then create eight equal partitions on the disk using the process in Disks. Do not use a partitioning scheme like this on a production system.

Danger

Eight partitions on one disk are not eight independent disks. Mirrors, spares, and other VDEVs made from those partitions all fail together if the physical disk fails. The following layout is solely for demonstrating the Sylve UI and resulting pool tree.

Arrange the eight partitions in the Create dialog as follows:

Partitions	VDEV type	Layout	What it demonstrates
p1, p2	Data	Mirror	A protected-looking primary Data VDEV.
p3, p4	Log (ZIL)	Mirror	A mirrored separate log VDEV.
p5	Cache (L2ARC)	Stripe	A cache VDEV, which only supports Stripe in the UI.
p6, p7	Special	Mirror	A redundant special VDEV layout.
p8	Spare	N/A	A hot spare assigned from the Spares drop zone.

Name the pool something clearly disposable, such as vdevlab. In the Devices tab, choose + Add VDEV for each VDEV, change the type before adding partitions, then drag each partition to its intended VDEV. The Spares area appears once the layout contains a non-stripe VDEV.

This layout intentionally does not include a Dedup VDEV. A useful Dedup VDEV needs its own redundant devices and is not safe to simulate with the remaining partitions on the same physical disk. Treat the Dedup VDEV type as a specialist production feature, not a way to improve ordinary pool performance.

Pool options

The Options tab applies creation-time properties and an optional mount point.

Option	Meaning	Practical guidance
Comments	A descriptive ZFS pool comment.	Record the pool’s purpose or workload.
Mount Point	Where the pool root is mounted. Leaving it blank uses the ZFS default /<pool>.	Use an absolute path such as /mnt/tank only when your layout requires it. Custom mount points are heavily discouraged.
Force Create	Allows a creation request that mixes Data VDEV RAID types.	Leave it off unless you intentionally understand the capacity and fault-domain consequences.
AShift	The pool’s sector-size exponent. Sylve offers 9 through 16 and defaults to 12.	Select the right value before creation. It is not a routine post-creation tuning option.
Auto Expand	Lets ZFS expand eligible devices when their capacity grows.	Enable only when that behavior matches your storage plan.
Auto Trim	Controls automatic discard or trim behavior.	Enable it only for storage that supports trim appropriately.
Delegation	Controls ZFS delegated administration.	Keep the default unless you have a defined delegation model.
Fail Mode	Controls how ZFS responds when it cannot complete I/O: wait, continue, or panic.	wait is the default. Change it only with a clear recovery policy.

Inspecting the pool tree and status

The pool table shows each pool’s name, size, used space, health, and primary redundancy. Expand a row to see the Data VDEVs and their devices. Separate L2 Cache, Logs, Spares, Special, and Dedup branches appear after the Data VDEVs when the pool contains them.

Select a pool and choose Status for the detailed ZFS status. It includes the pool state, status and action text supplied by ZFS, scan state, error summary, and the device tree. Use it to investigate degraded devices, checksum errors, a scrub, or a resilver.

Scrubbing, replacement, and detaching

Select a pool and choose Scrub to open Run Scrub / History / Schedule. All three tabs apply to that selected pool. Run Scrub shows the current scan and asks for confirmation before starting an integrity scan. A successful start request is not a completed scrub: Sylve tracks the new ZFS scan before reporting a result. Editing, replacement, detaching, and deletion are blocked while a Sylve-tracked scrub is active.

Recurring scrubs

Scrub scheduling is opt-in. Choose Add Schedule in the Schedule tab and choose a preset or enter a five-field cron expression for the selected pool. A pool can have multiple schedules, each with its own cron expression, enabled state, and last-run status. Schedule IDs identify the cards and their runs in History.

Preset	Cron expression	When it runs
Monthly	0 3 1 * *	Day 1 of each month at 03:00.
Weekly	0 3 * * 0	Every Sunday at 03:00.

Cron is evaluated in the node’s local timezone, including daylight-saving changes. Next/last run timestamps and history dates are displayed in browser-local time. Custom expressions must have minute, hour, day-of-month, month, and day-of-week fields; timezone prefixes and @every expressions are not accepted.

Only one scheduled scrub runs per node at a time. Scheduled scrubs wait behind that slot or a resilver on the same pool; a paused scrub still holds its slot. All schedules on a pool share a 24-hour minimum gap measured from scrub completion, not its start. An occurrence overlapping a scrub or falling within that gap is skipped, not postponed into a back-to-back scrub. The first eligible occurrence runs; redundant queued work is skipped with a reason in History. Schedules remain enabled for future eligible occurrences. Verified manual or external scrub completion also counts toward the gap; a failed start, unknown result, or skipped occurrence does not restart the cooldown.

Confirmed manual starts can override the cooldown, but never an active scan or a queued reservation. Manual scrubs on other pools and SMART tests remain independent, so plan maintenance windows to avoid unwanted I/O overlap. Disabling or deleting a queued schedule cancels only its queued work. Schedules for a pool with an active Sylve-tracked scrub cannot be edited or deleted.

After Sylve downtime, the scheduler catches up only the latest occurrence per schedule within 24 hours, subject to the same overlap/cooldown rule. Older work is recorded as missed rather than replaying every missed occurrence. Already queued work does not expire while waiting behind another pool’s long scan or a resilver, and additional occurrences of that schedule are coalesced instead of building a backlog. Redundant same-pool work is skipped even if its queue wait outlasts the cooldown. Sylve does not create or modify OS periodic/cron scrub jobs; account for any existing OS schedules separately.

Removing a pool from Sylve management or destroying it disables all its schedules and clears queued work while preserving history. These mutations are refused while a tracked scrub is active. Re-adding a pool does not automatically re-enable disabled schedules; a same-name replacement with a different GUID never inherits the old schedules.

Scrub results and notifications

History retains up to 64 terminal Sylve-tracked manual/scheduled occurrences per pool and never prunes active runs. It does not invent history for external scrubs. Results distinguish clean completion, completion with errors, cancellation, skipped or missed work, and unknown outcomes. Skipped entries have a reason, no actual start/duration, and no invented scan counters; they do not generate failure notifications. The pool’s cooldown is stored separately and survives history pruning, schedule deletion, and restart. Errors are counts; Repaired is a byte count, not the error count. Missing counters or progress are shown as unreported rather than zero.

Sylve reconciles persisted runs after restart without blindly issuing another scrub command. An unconfirmed start becomes unknown after five minutes of readable status without matching scan evidence. Transient inspection failures keep the run reserved; after 24 hours without usable scan status the result becomes unknown. A fresh scan check is still required before another scrub can start. A healthy or paused scrub has no fixed runtime timeout, and closing the dialog does not stop it. Pause, resume, and stop controls are not available in this version.

Configure ZFS Pool Scrub rules under System → Notifications → Rules for started, completed, failed-to-start, cancelled, unknown, and missed-run events. Rules target the stable pool GUID and display the pool name. Notification delivery failures do not rerun the scrub.

Select an eligible device row to reveal Replace Device or Detach Device. Replacement starts a ZFS replacement operation. Detaching removes the selected device from the pool when ZFS permits it. Neither operation is a substitute for verifying the pool’s redundancy and current health first.

Caution

A scrub can create substantial I/O on a busy pool. Schedule it for an appropriate maintenance window and monitor the resulting scan state in Status or the ZFS Dashboard.

Editing and deleting a pool

Select a pool and choose Edit to change its comment, Auto Expand, Auto Trim, Delegation, Fail Mode, and eligible spares. Spare management is available for pools with a mirror or RAIDZ layout. Sylve validates that any selected spare is large enough for the pool.

To remove a disposable pool, select it and choose Delete. Sylve refuses deletion when a dataset in the pool is still used by a Sylve-managed workload. Delete or move those dependencies first.

Danger

Deleting a pool destroys the pool and its datasets. It is not a secure erase of every physical block, but its data is no longer available as a ZFS pool. Back up or migrate anything you need before confirming deletion.