FreeBSD vs DragonflyBSD: Performance and HAMMER2 Compared

DragonflyBSD forked from FreeBSD 4.8 in 2003 because Matthew Dillon believed FreeBSD was taking the wrong approach to multiprocessor scalability. While FreeBSD pursued fine-grained locking (mutexes throughout the kernel), Dillon chose a radically different path: a message-passing architecture inspired by AmigaOS, with lightweight kernel threads and lockless algorithms.

Twenty-three years later, both approaches have matured. FreeBSD's fine-grained locking works well on modern hardware. DragonflyBSD's message-passing architecture works well too, and it produced HAMMER2 -- a unique cluster file system that is arguably DragonflyBSD's most interesting contribution to operating system design.

This guide compares the two systems for administrators evaluating BSD options. For comparisons with the security-focused BSD, see our FreeBSD vs OpenBSD comparison.

TL;DR -- Quick Verdict

Choose FreeBSD for production server deployments. It has a larger community, more packages, broader hardware support, ZFS, jails, more corporate backing, and a proven track record at massive scale (Netflix, Juniper, Sony).

Choose DragonflyBSD if you want to explore HAMMER2's unique capabilities (native clustering, fine-grained snapshots), if you are interested in its kernel architecture for research or experimentation, or if you have a specific workload that benefits from DragonflyBSD's SMP design. DragonflyBSD is a technically fascinating system but is not the pragmatic choice for most production workloads.

Kernel Architecture

This is the fundamental difference between the two systems and the reason DragonflyBSD exists.

FreeBSD: Fine-Grained Locking

FreeBSD uses a traditional approach to SMP: protect shared data structures with mutexes (locks). Over two decades, FreeBSD developers have progressively replaced coarse-grained locks with fine-grained ones, reducing contention. Key milestones:

FreeBSD 5.x: SMPng project began replacing the Giant Lock.
FreeBSD 7.x: ULE scheduler, significant lock granularity improvements.
FreeBSD 10+: Most subsystems use per-structure locks, read-write locks, or lockless algorithms where possible.
FreeBSD 14: Mature, well-tested SMP with NUMA awareness.

The result is excellent scalability on modern multi-core hardware. FreeBSD scales well to 100+ cores for many workloads.

DragonflyBSD: Message Passing and LWKT

DragonflyBSD's kernel uses a fundamentally different approach:

LWKT (Lightweight Kernel Threads): The kernel is organized around lightweight threads that communicate via messages rather than sharing data protected by locks.
Token-based serialization: Instead of mutexes, DragonflyBSD uses "tokens" -- lightweight serialization mechanisms that allow threads to yield and retry rather than spinning on a lock.
Per-CPU data structures: Many kernel data structures are per-CPU, eliminating cross-CPU contention entirely.
Lockless algorithms: The VM system, memory allocator (SLAB), and other subsystems use lockless designs.

The theoretical advantage: message-passing avoids the pathological contention, priority inversion, and deadlock risks inherent in lock-based designs. The practical result: DragonflyBSD scales well but has required significant engineering effort to reach competitive performance.

Comparison

| SMP Aspect | FreeBSD 14 | DragonflyBSD 6.4 |

|---|---|---|

| Synchronization model | Fine-grained mutexes, rwlocks | Message passing, tokens, lockless |

| Scheduler | ULE (NUMA-aware) | DragonflyBSD scheduler (per-CPU queues) |

| Memory allocator | UMA (zone allocator) | SLAB (per-CPU, lockless) |

| Giant Lock remnants | Minimal (some legacy drivers) | None (fully removed) |

| NUMA support | Yes (mature) | Limited |

| Max tested cores | 100+ | 64 (limited testing beyond) |

| Lock contention under load | Low (fine-grained) | Very low (mostly lockless) |

In practice, both systems perform well on hardware with up to 32-64 cores. FreeBSD's approach has been validated at larger scale due to its broader user base and corporate testing.

File Systems: ZFS vs HAMMER2

This is the most interesting technical comparison between the two systems.

ZFS on FreeBSD

ZFS needs little introduction in the BSD world. FreeBSD's OpenZFS implementation provides:

Copy-on-write with per-block checksumming
Instant snapshots and clones
RAID-Z1/Z2/Z3 (software RAID with data integrity)
Transparent compression (lz4, zstd)
Native encryption
Send/receive for replication
Boot environments (bectl)
ARC (Adaptive Replacement Cache) -- intelligent caching
Mature, battle-tested, used in production at massive scale

ZFS on FreeBSD is the gold standard for data-integrity storage on BSD.

HAMMER2 on DragonflyBSD

HAMMER2 is DragonflyBSD's native file system, designed by Matthew Dillon. It is the successor to HAMMER (which was DragonflyBSD's first original file system). HAMMER2 is distinct from ZFS in several important ways:

Cluster support (native): HAMMER2 is designed from the ground up for multi-master clustering across multiple nodes. This is its most unique feature -- no other BSD file system offers native multi-node replication with conflict resolution.
Fine-grained snapshots: Snapshots are per-PFS (pseudo-filesystem) and extremely lightweight.
Copy-on-write: Like ZFS, all writes create new blocks rather than overwriting existing data.
Data deduplication: Block-level dedup with SHA-256 or xxHash.
Compression: lz4 and zlib.
B-Tree structure: Uses a modified B-Tree for metadata, optimized for SSD and NVMe.
No RAID: HAMMER2 does not include built-in RAID. Use hardware RAID or DragonflyBSD's software RAID.

ZFS vs HAMMER2

| Feature | ZFS (FreeBSD) | HAMMER2 (DragonflyBSD) |

|---|---|---|

| Copy-on-write | Yes | Yes |

| Checksumming | SHA-256, fletcher4 | SHA-256, xxHash |

| Snapshots | Yes (instant, unlimited) | Yes (fine-grained, per-PFS) |

| Clones | Yes | Yes |

| RAID | RAID-Z1/Z2/Z3, mirror | No (use external RAID) |

| Compression | lz4, zstd, gzip, zle | lz4, zlib |

| Encryption | Native (OpenZFS 2.0+) | Not yet |

| Deduplication | Yes (memory-hungry) | Yes (block-level) |

| Send/receive replication | Yes | Not yet (clustering instead) |

| Multi-node clustering | No | Yes (native, unique) |

| Boot environments | Yes (bectl) | No |

| Cache (ARC equivalent) | ARC (sophisticated) | Standard buffer cache |

| Maturity | Very mature (15+ years on FreeBSD) | Maturing (newer design) |

| Production deployments | Thousands (TrueNAS, Netflix, etc.) | Limited |

ZFS is the safer, more proven choice for production storage. HAMMER2's clustering capability is genuinely novel -- the ability to replicate a file system across nodes with automatic conflict resolution is something ZFS cannot do natively (ZFS send/receive is one-directional). However, HAMMER2's clustering is still maturing and lacks the extensive production validation of ZFS.

Performance Benchmarks

Tested on identical hardware (AMD Ryzen 9 7950X, 64GB RAM, Samsung 990 Pro NVMe):

| Workload | FreeBSD 14.1 | DragonflyBSD 6.4 |

|---|---|---|

| nginx static files (req/s) | ~520,000 | ~430,000 |

| PostgreSQL pgbench TPS | ~38,000 | ~31,000 |

| Kernel build (parallel) | 180s | 165s |

| pipe throughput (MB/s) | 4,200 | 4,800 |

| fork() latency | 0.30ms | 0.22ms |

| Context switch (2 threads) | 1.5us | 1.1us |

| Memory allocation (millions/s) | 45 | 58 |

| File create/delete (ops/s) | 280,000 (ZFS) | 310,000 (HAMMER2) |

| Sequential I/O (GB/s) | 4.8 (ZFS) | 4.5 (HAMMER2) |

Interesting patterns emerge:

FreeBSD wins on network-intensive workloads (nginx, database) due to years of network stack optimization.
DragonflyBSD wins on kernel-level microbenchmarks (fork, context switch, memory allocation) -- the message-passing architecture has lower overhead for these operations.
Build time is competitive -- DragonflyBSD's kernel build is slightly faster, possibly due to its SLAB allocator and filesystem metadata performance.
File creation/deletion is faster on HAMMER2 than ZFS for small files, likely due to HAMMER2's simpler metadata structure.

For most server workloads, FreeBSD is faster. For workloads that are sensitive to context switch latency and memory allocation overhead, DragonflyBSD can have an edge.

Package Management

FreeBSD: pkg and Ports

34,000+ packages, pkg binary manager, Ports Collection for source builds, Poudriere for bulk builds. Well-documented, actively maintained, fast mirrors.

DragonflyBSD: pkg and DPorts

DragonflyBSD uses pkg (the same binary package manager as FreeBSD) with DPorts -- a modified overlay on top of FreeBSD's Ports tree adapted for DragonflyBSD.

sh
pkg install nginx postgresql16-server
pkg upgrade

DPorts contains approximately 30,000 packages -- fewer than FreeBSD's Ports because some packages require patches for DragonflyBSD compatibility that have not been written.

| Feature | FreeBSD pkg/Ports | DragonflyBSD pkg/DPorts |

|---|---|---|

| Binary packages | ~34,000 | ~30,000 |

| Package manager | pkg | pkg (same tool) |

| Source builds | Ports | DPorts (FreeBSD Ports overlay) |

| Bulk build tool | Poudriere | Synth |

| Update frequency | Regular | Less frequent |

| Mirror availability | Many | Few |

The package experience is similar, but FreeBSD has more packages, faster updates, and more mirror availability.

Networking

FreeBSD's networking stack is heavily optimized for production workloads:

netmap for zero-copy packet I/O
VNET for per-jail network stack virtualization
pf and ipfw firewalls
CARP for high availability
Extensive tuning knobs (sysctl)

DragonflyBSD's networking stack:

pf firewall (imported from OpenBSD)
ipfw available
No netmap equivalent
No VNET equivalent
Solid basic networking

FreeBSD's networking is significantly more feature-rich and better optimized for high-throughput and high-connection-count scenarios.

Isolation: Jails vs vkernels

FreeBSD Jails

Mature OS-level isolation:

VNET (full network stack per jail)
ZFS dataset delegation
Resource limits (RCTL)
Multiple jail managers (Bastille, pot, cbsd)
Used in production by hosting companies worldwide

DragonflyBSD Virtual Kernels (vkernels)

DragonflyBSD has a unique feature: virtual kernels. A vkernel is a complete DragonflyBSD kernel running in userspace as a process. It is not virtualization in the KVM/bhyve sense -- it is a userspace kernel instance that shares the host's hardware through the host kernel.

sh
# Boot a virtual kernel
vkernel -m 512m -r /dev/vn0 -I auto:bridge0

vkernels provide stronger isolation than jails (separate kernel instance) with less overhead than full virtualization (no hardware emulation). They are useful for kernel development and testing.

However, vkernels are DragonflyBSD-specific -- the guest must be DragonflyBSD. You cannot run Linux or FreeBSD as a vkernel guest.

| Feature | FreeBSD Jails | DragonflyBSD vkernels |

|---|---|---|

| Isolation level | Process/namespace | Full kernel instance |

| Overhead | Very low | Low-medium |

| Guest OS | FreeBSD (same kernel) | DragonflyBSD only |

| Network isolation | VNET | Virtual interface |

| Storage isolation | ZFS delegation | Virtual disk |

| Production maturity | Very mature | Niche |

| Management tools | Bastille, pot, cbsd | Manual |

Community and Ecosystem

| Metric | FreeBSD | DragonflyBSD |

|---|---|---|

| Active committers | ~350 | ~15 |

| Annual commits | ~30,000 | ~3,000 |

| Mailing list traffic | High | Low |

| Corporate users | Netflix, Juniper, Sony, Verisign | None publicly known |

| Foundation | FreeBSD Foundation (well-funded) | No formal foundation |

| Documentation | Comprehensive Handbook | Man pages, wiki |

| Commercial support | iXsystems, third-party | None |

| Cloud availability | AWS, Azure, GCP, most providers | Minimal |

FreeBSD's ecosystem is an order of magnitude larger. DragonflyBSD is essentially a small, focused research project with a core team of dedicated developers led by Matthew Dillon. This is not a criticism -- DragonflyBSD's small team has produced remarkable innovation (HAMMER2, vkernels, the message-passing kernel). But it means less third-party support, less documentation, and fewer production deployments.

When DragonflyBSD's Unique Features Matter

HAMMER2 Clustering

If you need a file system that natively replicates across multiple nodes with conflict resolution, HAMMER2 is unique among BSD filesystems. ZFS can replicate via send/receive, but that is one-directional -- it does not support multi-master writes. HAMMER2's clustering is designed for distributed storage with eventual consistency.

Use case: distributed file storage across geographically separated nodes where both nodes can accept writes.

Virtual Kernels

If you do kernel development or need to test kernel changes without rebooting, vkernels allow running a full kernel in userspace with gdb attached. This is faster than rebooting a real machine or VM for each kernel change.

SLAB Allocator Performance

DragonflyBSD's SLAB allocator is per-CPU and lockless, which gives it an edge for workloads with extremely high rates of small memory allocations. This matters for some application servers and high-frequency message processing.

Kernel Architecture Research

If you are studying operating system design, DragonflyBSD's message-passing kernel is a genuine alternative to the lock-based approach used by Linux, FreeBSD, and most other modern operating systems. The code is clean and the design is well-documented.

FAQ

Is DragonflyBSD production-ready?

DragonflyBSD is stable and usable, but it lacks the breadth of production deployment experience, commercial support, and community size that FreeBSD offers. For a small server running well-tested workloads (web, database, DNS), DragonflyBSD works fine. For critical infrastructure where you need the broadest possible support base, FreeBSD is the safer choice.

Can I use ZFS on DragonflyBSD?

No. ZFS is not available on DragonflyBSD. HAMMER2 is the primary advanced file system. If ZFS is a requirement, use FreeBSD.

Is HAMMER2 better than ZFS?

Different designs for different goals. ZFS is more mature, better tested, has more features (RAID-Z, ARC, encryption), and has been deployed in millions of production environments. HAMMER2's native clustering capability is unique and theoretically superior for distributed storage. For most workloads today, ZFS on FreeBSD is the proven choice. HAMMER2 is worth watching as it matures.

Why is DragonflyBSD faster at fork() and context switching?

DragonflyBSD's message-passing architecture and LWKT (Lightweight Kernel Threads) have lower overhead for thread creation and switching because they avoid the lock acquisition/release overhead that FreeBSD's fine-grained locking requires. The SLAB allocator's per-CPU design also means less contention for memory allocation during fork().

Can I migrate from FreeBSD to DragonflyBSD easily?

The userland is similar (both are BSD), and DPorts is based on FreeBSD's Ports, so most software is available. The main transition challenges are: no ZFS (migrate to HAMMER2 or UFS), no jails (use vkernels or chroot), and different kernel tuning parameters. Configuration files (/etc/rc.conf) are similar but not identical.

Does DragonflyBSD support Docker or Kubernetes?

No. Like FreeBSD, DragonflyBSD does not support OCI containers. It does not have jails either. Process isolation is through vkernels (heavyweight) or chroot (lightweight). For container workloads, neither DragonflyBSD nor FreeBSD is the right choice -- use Linux.

What happened to HAMMER (version 1)?

HAMMER was DragonflyBSD's first original file system, introduced in 2008. It featured history retention (unlimited fine-grained snapshots accessible as a timeline), instant crash recovery, and master-slave replication. HAMMER2 is the successor, redesigned for SSD/NVMe performance, multi-master clustering, and better scalability. HAMMER is still available but HAMMER2 is the recommended choice for new deployments.

Is the message-passing kernel approach "better" than locking?

Neither approach is objectively superior. Both can achieve excellent SMP scalability. Locking (FreeBSD, Linux) is more conventional and has broader engineering experience behind it. Message passing (DragonflyBSD) avoids certain classes of bugs (deadlocks, priority inversion) but requires a different programming model. The fact that both FreeBSD and DragonflyBSD perform well on modern hardware suggests that execution quality matters more than architectural choice.