Your filesystem is lying to you.
Here's something most people never think about: when you save a file on ext4 or XFS, the filesystem writes it to disk and says "done." But it never checks whether what it wrote is actually what you gave it. It just trusts the hardware.
Hardware lies. Disks develop bad sectors. Controllers have firmware bugs. Cables get loose. Cosmic rays flip bits. These aren't hypotheticals — they're Tuesday. And your filesystem has no idea it happened. Your data is silently corrupted, and you won't find out until you try to open that file six months from now.
ZFS doesn't trust hardware. Every block of data gets a cryptographic checksum. Every time ZFS reads a block, it verifies the checksum. If the data doesn't match, ZFS knows it's corrupt — and if you have a mirror or RAIDZ, it automatically fetches a good copy and fixes it. While you sleep.
This is not paranoia. A 2007 CERN study found that 1 in 1500 files developed silent data corruption on enterprise storage within six months. Google's 2009 study of 1.5 million drives found bit error rates far exceeding manufacturer specs. Netflix runs zpool scrub across their entire fleet because they've seen what happens when you don't. If your data matters — and if it doesn't, why are you storing it? — you need a filesystem that verifies every read. ext4 doesn't. XFS doesn't. NTFS doesn't. ZFS does.
The features that change everything
Checksums on Everything
Every block. Every metadata structure. Every pointer. ZFS builds a Merkle tree — the same data structure Bitcoin uses — from the bottom of your storage up to the root. If anything changes without ZFS knowing, it catches it.
Copy-on-Write
ZFS never overwrites data in place. When you modify a file, it writes the new version to a new location, then atomically updates the pointer. If power fails mid-write, you have either the old version or the new version. Never a half-written mess.
Snapshots in Milliseconds
A snapshot doesn't copy your data. It just says "remember this moment." Because ZFS never overwrites blocks, the old blocks are simply preserved. A snapshot of a 500GB filesystem takes less time than pressing Enter.
Built-in Compression
Every write is transparently compressed before hitting disk. LZ4 compression adds nearly zero CPU overhead but typically gives you 1.5–2x more usable space. You don't configure it. You don't think about it. It just works.
Self-Healing
On a mirror or RAIDZ pool, when ZFS detects a corrupt block, it doesn't just report it — it fetches the good copy from the redundant disk and overwrites the bad one. Automatically. No downtime. No intervention.
No fsck. Ever.
Traditional filesystems need to be checked after a crash. That's fsck,
and on a large filesystem, it can take hours. ZFS doesn't need fsck because its
copy-on-write design means the on-disk state is always consistent. You boot. It's fine.
What none of this mentions: datasets.
The features above are impressive on their own. But the real power of ZFS isn't any single feature — it's that every feature applies independently per dataset. A dataset is not a directory. It's an independent storage domain with its own compression algorithm, its own encryption key, its own snapshot timeline, its own quota, its own recordsize, its own replication stream.
Your database gets recordsize=8K and logbias=throughput. Your media library gets recordsize=1M and compression=off. Your logs get compression=zstd-19. Your home directories each get their own encryption key. All on the same pool. All snapshotted independently. All replicable independently. This is what turns ZFS from "a better ext4" into "a completely different way of thinking about storage."
The licensing "problem"
ZFS was built by Sun Microsystems under the CDDL license. Linux uses the GPL. Some lawyers say these two licenses are incompatible, which means ZFS can't be shipped inside the Linux kernel. It has to be built as a separate module.
That's it. That's the whole "problem." Not a technical problem. Not a quality problem. Not a "ZFS doesn't work on Linux" problem. A licensing paperwork problem. And because of this paperwork, most Linux distributions refuse to include ZFS out of the box, leaving users to figure it out themselves.
Let's be clear about what this means: the best filesystem in existence is kept away from the most popular operating system on Earth because of two documents written in the 1990s by people who never imagined this situation. Linux users are left with ext4 (solid, but no checksums, no snapshots, no self-healing) or btrfs (ambitious, but not ready for the trust level ZFS has earned over two decades).
kldload exists because that's ridiculous. It builds the module at image creation time, signs it with a per-build MOK key, embeds it in the initramfs, and ships it alongside the kernel as a matched pair. No compiler on the target. No DKMS in the boot path. No hoping the next kernel update doesn't break everything.
FreeBSD has had this figured out since 2007. ZFS has been a first-class citizen in the FreeBSD kernel for almost twenty years. It's the default for TrueNAS. It's battle-tested on millions of systems. On FreeBSD, kldload zfs loads a module that ships with the kernel. No DKMS. No build tools. No license conflict. The code is identical to what runs on Linux — same OpenZFS codebase. Linux just makes you fight to use it.
That's what the name means. kldload is the FreeBSD command to load a kernel module. kldload the tool does the same thing for Linux: loads the modules that should be there but aren't. The BSD people solved this 20 years ago. This tool brings their answer to Linux.