ZFS for video editors, explained plainly

ZFS is the filesystem that quietly protects your footage from going bad while it sits on the drive, and it is the reason a self-hosted NAS can be trusted with masters you cannot reshoot. If you run a NAS for video, you are probably already on ZFS or about to be: TrueNAS uses it, QNAP's QuTS hero is built on it, and most build-your-own boxes land there too. This is the plain-English version of what ZFS is doing for you, what the jargon means, and the handful of settings that actually matter for editing.

Why ZFS protects media better than a plain drive #

The single best thing ZFS does for editors is catch and repair bit rot before it eats a frame. Every block ZFS writes gets a checksum stored alongside it, separate from the data. The default checksum in OpenZFS is Fletcher4, with SHA-256 available if you want cryptographic strength (OpenZFS docs, checked Jun 2026). When ZFS reads a block back, it recomputes the checksum and compares. If they do not match, ZFS knows that block is wrong, even though the drive itself reported a clean read and a normal hard drive would have handed you the corrupted bytes without a word.

Think of it like a tamper-evident seal on every box in a warehouse. A regular filesystem hands you whatever is in the box and trusts the box. ZFS checks the seal on the way out, and if the seal is broken it goes and grabs a known-good copy from a redundant box, gives you that, and quietly re-seals the broken one. That repair-on-read behavior is what people mean by self-healing: in a mirror, ZFS uses the checksum to tell which copy is correct; in a parity setup it rebuilds the bad block from parity and writes the good version back (Klara Systems, "Understanding ZFS Scrubs," checked Jun 2026). The other half of this is a scrub, a scheduled pass that reads every block in the pool and verifies it against its checksum so corruption gets caught and fixed on a Sunday night instead of the day you open a three-year-old project. Run one monthly. This matters more for media than almost any other data because a single flipped bit in a long-GOP H.264 file can corrupt everything downstream of that frame, and you usually do not find out until you scrub through the timeline months later.

Pools and vdevs, the only two words you must know #

ZFS has its own vocabulary, but you only need two terms to make good decisions. A vdev (virtual device) is a group of physical drives that handle redundancy together. A pool is one or more vdevs stitched into a single block of storage that your datasets and shares live on. The catch that trips people up: ZFS stripes data across the vdevs in a pool, so the pool is only as resilient as its vdevs, and you cannot remove a vdev from a pool once it is in (with the narrow exception of certain mirror and special configs). Plan the vdev layout before you pour data in.

The analogy I use: a vdev is a single bookshelf with its own bracing so it will not topple, and a pool is the whole wall of bookshelves you treat as one library. Add a sturdy shelf and the library grows. But if you bolt in a flimsy unbraced shelf, the weakness is now part of the wall. That is why a pool made of one big parity vdev behaves very differently from a pool made of several mirror vdevs, which is the next decision.

RAIDZ vs mirrors: capacity or speed #

This is the choice that decides how your NAS feels. RAIDZ is ZFS's parity layout, similar in spirit to RAID-5 or RAID-6: RAIDZ1 survives one drive failure, RAIDZ2 survives two, RAIDZ3 survives three, and you get most of your raw capacity. Mirrors keep full copies of data, so a pool of mirrors costs you half your raw capacity but reads and writes far faster for the random work editors actually do.

The reason comes down to IOPS, the count of small operations per second. Each RAIDZ vdev gives you roughly the IOPS of a single drive in it, no matter how many drives are in the vdev, because every read has to touch the whole stripe. A pool of mirrors scales read IOPS with the number of drives, so it handles many editors scrubbing many clips at once much more gracefully (Klara Systems, "Designing a Storage Pool," checked Jun 2026). Resilver time follows the same logic: mirrors rebuild fastest, and RAIDZ rebuild performance is fine up to about five drives per vdev but degrades as the vdev gets wider. The honest read for video: large libraries of finished masters that get streamed sequentially are happy on RAIDZ2 and you keep your capacity. A small, busy edit pool with several seats hammering proxies and timelines is better served by mirrors. Many post houses split the difference with a RAIDZ2 spinning-disk pool for bulk and a small mirror or all-flash pool for active projects.

One genuinely good development: OpenZFS 2.3 shipped in January 2025 with RAIDZ expansion, so you can finally add a single drive to an existing RAIDZ vdev. ZFS rewrites the data across all drives including the new one, which can take days, but the array stays online and fault-tolerant the whole time and the new space appears when it finishes (Phoronix and The Register, Jan 2025, checked Jun 2026). Before this, growing a RAIDZ vdev meant replacing every drive one at a time or building a new pool. If you are weighing whole NAS platforms around this, our roundup of storage appliances for creatives in 2026 and the in-progress guides on TrueNAS for video editing and QNAP for creatives go deeper on the hardware.

The one setting that matters most: recordsize #

If you change one ZFS knob for media, change recordsize. It defaults to 128KiB, which is a reasonable general-purpose value but small for video (Klara Systems, "Tuning recordsize in OpenZFS," checked Jun 2026). Set recordsize=1M on the dataset that holds your footage. Because video files are large and read sequentially, the bigger record means fewer blocks per file, which means less metadata to track, fewer I/O operations to stream a clip, fewer indirect blocks, and less fragmentation over the life of the pool. ZFS still stores genuinely tiny files in tiny blocks, so a 1M recordsize does not waste space on your small sidecar files.

The gotcha that bites everyone: recordsize only applies to files written after you change it. The block layout of a file is locked in when its first block is written, so flipping the setting does nothing for footage already on disk. To convert existing files you have to actually rewrite them with a copy or rsync within the dataset, and ZFS replication will not resize blocks for you either (Klara Systems, checked Jun 2026). Set recordsize on the dataset before you migrate your library, not after. Leave compression on while you are in there: TrueNAS defaults datasets to LZ4, which is fast and nearly free on a modern CPU, and zstd is available if you want a better ratio at slightly more CPU cost (TrueNAS documentation and community, checked Jun 2026). Compression rarely shrinks already-compressed video much, but it costs almost nothing and helps your project files and caches.

ARC, L2ARC, SLOG, and special vdevs without the mystery #

ZFS has a cluster of cache and log devices that sound intimidating and mostly are not. ARC is the read cache that lives in RAM, and it is the single biggest reason a well-specced ZFS box feels fast: hot blocks get served from memory at memory speed. Feed it RAM before you reach for anything exotic. L2ARC is an SSD second-tier read cache for blocks that overflow the ARC, but it is not free, because ZFS has to keep an index of the L2ARC in RAM, so a huge L2ARC on a RAM-starved box can actually hurt (Klara Systems, "All About the L2ARC," checked Jun 2026). For metadata-heavy and random-read pools, a special vdev (a mirrored SSD pair that holds metadata and small blocks) often beats throwing an L2ARC at the problem, with the caveat that a special vdev is part of the pool and must be redundant because losing it loses the pool.

SLOG is the one editors most often misunderstand. It is not a write cache. It only matters for synchronous writes, which on a NAS mostly means NFS, where v3 and v4 write synchronously by default. If you serve media over SMB to editing seats, your writes are usually asynchronous and a SLOG does nothing for you (TrueNAS community, checked Jun 2026). Do not buy an SSD for a SLOG you will never use. The practical priority order for an edit NAS: plenty of RAM first, then fast primary vdevs (mirrors or flash for the active pool), then a special vdev if your workload is metadata-heavy, and an L2ARC or SLOG only when a specific measured bottleneck calls for it.

Where ZFS ends and the mount layer begins #

ZFS is the foundation under your storage. It does not, by itself, make that storage feel like a fast local Finder volume for an editor sitting across a network, and it does nothing about a slow link or a missing local search index. That is a separate layer. JuiceMount is the part I work on: it turns a self-hosted NAS into a real mount with block-level streaming and a local SSD cache, and it sits happily on top of a ZFS pool, but it does not replace ZFS and it will not fix a pool you laid out badly. Get the vdev layout and recordsize right at the ZFS level first; the mount layer cannot undo those decisions. For the boundary between block-level streaming and whole-file sync, see block-level streaming vs whole-file sync, and if any of these terms are still fuzzy, the storage glossary for editors is the companion piece.