Announcement

New LTS for FreeBSD is now available in an initial release  Learn More

Klara
Emergency Help
Use case · High-Performance / Large-Scale

ZFS performance engineering at scale

When tuning alone isn’t enough, Klara’s engineers work in the OpenZFS and FreeBSD source code: profiling, patching and upstreaming fixes so your storage keeps up with your hardware.

Talk to an engineer
See custom development
Built on
  • OpenZFS
  • FreeBSD
  • Linux
Who it's for
  • Cloud and storage providers running petabyte-scale ZFS
  • Platforms with large ARC, NVMe pools or thousands of datasets
  • Teams that have hit a performance limit nobody has documented yet
Performance at scale

What changes when ZFS runs at scale

At large scale, the hard problems are rarely in the manual. They show up in your workload, on your hardware, and often need a fix in the source code.

Limits that only appear under real load

Lock contention, memory pressure and ARC behaviour at hundreds of terabytes rarely show up in a lab. They show up in production, on your workload, at the worst possible time.

Fast hardware the software isn't using

NVMe pools and high core counts can outpace default code paths. When throughput stalls well below what the drives can deliver, the bottleneck can be found and engineered out.

Local patches you carry forever

An in-house fix keeps things running until the next upgrade breaks it. Getting the change into OpenZFS upstream means it is reviewed, tested and shipped with every release.

Proof

“Klara’s expert team identified limitations between OpenZFS and the Linux memory subsystem, implemented patches that fully solved our performance issues, and upstreamed those fixes. We’re now getting the absolute most out of our hardware — and contributing back to the community.”

Rob Mueller, CTO, Fastmail · Internet Software and Services · Australia

How Klara helps

The services behind this solution

Each links to the full service page.

ZFS

ZFS Performance Audit

Profiling of your pools, ARC and I/O path under production load, with a written list of bottlenecks and fixes ranked by impact.

→
ZFS dev

ZFS Caching Enhancements – L2ARC

Engineering work on ARC and L2ARC behaviour so large caches and fast devices serve your hot data where it matters.

→
ZFS dev

Custom Feature Development

New OpenZFS features and code changes built for your workload, designed from day one to be accepted upstream.

→
ZFS dev

Upstreaming

We take your patches through review into OpenZFS and FreeBSD, so you stop maintaining a private fork.

→
How a ZFS performance engagement works

From profiling to upstream in three steps

1

Profile the system under real load

We instrument your production or staging systems with DTrace/eBPF, flame graphs, and ZFS kstats to find where time is actually spent, then agree on a measurable target.

2

Engineer the fix

Depending on our findings, that means configuration and topology changes, code changes in OpenZFS, or the FreeBSD/Linux integration layer, reviewed by our ZFS developers.

3

Ship and upstream

We validate against your baseline, help roll the change out across your fleet and submit code fixes upstream, so the improvement survives every future release.

Go deeper

Additional Resources

On-demand webinar

The Right Way to Benchmark ZFS: Avoiding Pitfalls and Misleading Metrics

Watch now

Article

ZFS Performance Tuning in the Real World: ARC, L2ARC, and SLOG

Read now

Article

Extending ZFS Performance Without Hardware Upgrades

Read now

Get started

Talk to the engineers who work on the OpenZFS code

Tell us about your scale, your hardware and where performance falls short. Our teams have a 72h response time, so someone will reach out shortly.

Production down right now?

Get Emergency Help