zfs_skill

This skill helps you manage ZFS pools, datasets, snapshots, and replication, optimizing performance and reliability across OpenZFS on Linux and macOS.
  • Python

2.5k

GitHub Stars

2

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill openclaw/skills --skill zfs

  • _meta.json262 B
  • SKILL.md5.2 KB

Overview

This skill provides practical ZFS administration for OpenZFS on Linux and macOS. It covers pool creation and management, dataset configuration, snapshots, replication, encryption, performance tuning, and troubleshooting. Advice emphasizes production-safe defaults and real-device best practices. Use it for hands-on commands, planning, and recovery steps.

How this skill works

The skill inspects pool and dataset topology, recommends commands and property values, and generates safe examples for create/replace/add operations. It builds step sequences for snapshots, zfs send/recv replication, key management for encryption, and performance tuning changes. It flags risky patterns (like file-backed pools) and offers platform-specific notes for Linux and macOS. It also provides diagnosis steps for degraded pools, scrubs, and resilver operations.

When to use it

  • Create or expand zpools and vdevs with production-safe defaults
  • Configure datasets, compression, recordsize, and inheritance for workloads
  • Set up snapshots, retention policies, and replication (zfs send/recv)
  • Enable or manage dataset encryption and key handling
  • Tune performance (ARC, recordsize, compression, SLOG/L2ARC, special vdevs)
  • Troubleshoot degraded/faulted pools, scrub errors, and resilver issues

Best practices

  • Always use real block devices in production; file-backed pools are only for testing or demos
  • Specify ashift=12 (or 13 for certain NVMe) when creating pools to match sector size
  • Set compression=lz4 and atime=off by default; tune recordsize per workload (database vs media)
  • Plan vdev layout carefully; vdev additions are irreversible—prefer multiple smaller vdevs over one very wide vdev
  • Use encrypted datasets for sensitive data; manage keys with secure keylocation and automate load/unload in controlled scripts
  • Perform regular scrubs and monitor capacity; avoid operating pools above recommended thresholds (typically >80%)

Example use cases

  • Create a mirrored production pool with ashift and device-by-id names for stable IDs
  • Configure datasets: small recordsize for Postgres, large recordsize for media/backups, enable lz4 compression
  • Set up daily recursive snapshots and a remote replication workflow using zfs send/recv over SSH
  • Replace a failing disk and monitor resilver progress; recover a degraded pool using spare or replace sequence
  • Create an encrypted dataset with keylocation=file:///etc/zfs/keys and automate key loading on boot

FAQ

No. File-backed pools forfeit ZFS reliability and performance; reserve them only for learning or CI tests and explicitly note they are non-production.

What ashift should I use when creating pools?

Use ashift=12 for most SATA/SMR drives. Consider ashift=13 for some NVMe devices with 4K physical sectors; match ashift to device physical sector size.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational