OpenZFS Block Cloning in Production: BRT Internals, the 2.2 Corruption Incident, and Safe Rollout

Wed, 29 Jul 2026 09:00:00 -0500

Copying a 21 GiB virtual machine image on a pool with block cloning enabled finishes in about a quarter of a second and consumes no additional space. The copy is a real, independent file: it has its own inode, its own permissions, and its own future. It simply points at the same on-disk blocks as the original until one of them is modified. This is block cloning, the OpenZFS implementation of what XFS, Btrfs, and Windows ReFS call a reflink, and it is one of the highest leverage storage features available to anyone running VM fleets, container image caches, or backup pipelines.

It is also the feature that shipped enabled by default in OpenZFS 2.2.0, silently corrupted files for a subset of users, got emergency-disabled in 2.2.1, and then spent the better part of two years switched off by default while the project rebuilt confidence in it. That history is not a reason to avoid block cloning. It is a reason to understand exactly what it does, which version floor is safe, how to verify it is actually engaging, and where the savings quietly evaporate. This guide covers the mechanism, the incident, and the operational practices that make it safe to turn on.

OpenZFS on Support Tools

OpenZFS Block Cloning in Production: BRT Internals, the 2.2 Corruption Incident, and Safe Rollout