Fast EC ships switched off: the Ceph Tentacle flag that only turns once

Ceph Tentacle ships the erasure coding performance work that had been on the wish list for years. On the developers' own test bench, with a 6+2 profile and a 16K stripe_unit, small writes "at least double" the throughput compared with Squid. Two things the headline leaves out: that 16K is precisely what an existing pool cannot have, and Fast EC arrives switched off. You enable it pool by pool, with one command, and the monitor then refuses to clear it.

We are writing this because it is the kind of detail that gets lost between the release note and the maintenance window. Proxmox VE 9.2, released in May, already ships Ceph Tentacle 20.2.1 as the default stable release — with Squid 19.2.3 still available as an option. Plenty of people already have Tentacle installed. And are still reading the same performance numbers as before.

What Fast EC does, one sentence per optimisation

The original sin of erasure coding is well known: to touch one byte you had to move the whole stripe. The four optimisations the Ceph team describes attack precisely that.

• Partial reads. Only the minimum needed is read instead of the full stripe. That is where the two-to-three-times gain on small block and file reads comes from.
• No more small-object padding. Small objects are no longer padded out to a full stripe. This is not a speed gain, it is a space one: it is the "amplification" half of the headline.
• Partial writes. Only the modified strips are read before re-encoding parities, not all of them.
• Parity delta writes (PDW). Ceph borrows a classic RAID controller technique: read the old data, XOR it with the new data and apply the delta to the parity. With m=2, that is three reads and three writes per strip.

The numbers, with the test bench in plain sight

It is worth looking at where they were measured: a single node, eight OSDs on NVMe, two Intel Xeon Platinum 8276M at 2.20 GHz with 28 cores per socket. On a mixed workload — 70% reads and 30% writes of around 16k, the typical pattern for transactional and file applications — "compared with Squid, there is at least a doubling in throughput with FastEC". The specific comparison is Squid at 4K against Tentacle at 16K, both 6+2.

And the sentence that follows in the same article, which almost nobody quotes because it spoils the headline: "three-way replica is still faster" — the 6+2 pool with Fast EC lands at around half its performance. Fast EC does not win that argument, it narrows it. The Ceph team round it off with an honest line that is worth the whole article: with erasure coding "you get half the performance at less than half the cost". That is a trade, not a victory.

That test bench is not your cluster either. Fast EC cuts CPU and I/O work inside the node; if your bottleneck is a 10 GbE network shared with VM traffic, or spinning disks, the gain will be far more modest, because the problem was never there. A single-node lab number is not a promise for three nodes in production: it tells you what has been fixed, not how much you will gain. If this sounds like the same old conversation about erasure coding versus 3-way replication, that is exactly what it is: it moves one term in the maths we did back then, without flipping the answer.

One command, one pool, one direction

Fast EC is enabled per pool with a flag:

ceph osd pool set <pool> allow_ec_optimizations true

On Proxmox, an erasure coded pool is actually created as two: a replicated one for metadata and another for the data, which is the one carrying the -data suffix. The Proxmox documentation uses that suffix in its example, and it is worth noticing: the name you see in the interface is not the pool you run the command against.

The Ceph documentation warns without decoration: "once the flag has been enabled for a pool it cannot be disabled because it changes how new data is stored". Proxmox translates that into operations language and is blunter still: it is a one-way switch, the monitor refuses to clear the flag again, and rolling back requires draining and recreating the pool.

That is the criterion that matters to us: anything you undo by "draining and recreating the pool" is not a configuration option, it is a migration. It is closer to changing a column type in a database holding twenty terabytes than to ticking a box. And migrations get planned, tested on a small pool first, and done inside a window.

The four conditions the monitor enforces

Proxmox lists them as four requirements the Ceph monitor enforces. All four can be checked in two minutes:

• The whole cluster on Tentacle, and declared as such. The flag cannot be set until all monitors and OSDs are upgraded, and the cluster must be at require_osd_release tentacle or later. That last step is manual and comes after the packages: it is the one most often left half-done. Check it with ceph osd dump | grep require_osd_release.
• That the pool is erasure coded. A pool's name tells you nothing about its type; ceph osd pool ls detail does.
• Compatible plugin and technique. Optimizations "are currently only supported with the Jerasure and ISA-L plugins when using the reed_sol_van technique". Check it with ceph osd erasure-code-profile get <profile>.
• That the pool's stripe_unit is a multiple of 4096 bytes. The default already satisfies this, so it only affects pools created with a custom stripe_unit. Tentacle explicitly denies EC optimizations for non-4k-aligned chunk sizes.

There is a fifth one Proxmox does not list and the Ceph documentation does: the pool must reside on BlueStore OSDs, because BlueStore's checksumming is used during deep scrubs. On a cluster built in the last few years this holds without thinking about it; on an inherited FileStore one, it is the first thing to check.

The other half of the gain you decided years ago

The Ceph documentation has been warning for years about something almost nobody reads when creating their first pool: "choosing the right profile is important because the profile cannot be modified after the pool is created". The k, the m, the plugin and the technique are frozen on creation day. And the stripe_unit, which is specified when the profile is created, cannot be touched afterwards either.

This is where the improvement splits in two. The default stripe_unit is still 4K in Tentacle, and the Ceph team recommends 16K for new pools that will use Fast EC — up to 256K where the workload is predominantly reads, at the cost of wasting capacity on small files and objects. For pools that already exist, the wording is literal: "for existing pools, it is not possible to change the stripe_unit, fast EC can still be enabled for these pools but there will be a slightly less performance improvement". Tie that back to the headline: the "at least double" was measured against a 16K pool; on the 4K you actually have, the source itself promises "slightly less". And anyone who once picked a jerasure technique other than reed_sol_van — cauchy_good, liberation and friends — gets nothing at all: for that pool there is no switch, there is a new pool and a data move.

ISA-L takes over from jerasure

The quiet change in this release is that ISA-L becomes the default plugin for erasure coded pools. Tentacle's default profile now comes out with plugin=isa, k=2, m=2 and technique=reed_sol_van; on Squid, that same page showed plugin=jerasure. The documentation explains why without diplomacy: the jerasure library "is no longer maintained and has not been updated to support modern CPU instructions" that speed up encoding and decoding.

There is also a dated warning, not yet in the Tentacle documentation but in the development branch (we checked it on 7 August 2026): techniques other than reed_sol_van are marked deprecated and support will be removed in the Vampire release. If you have a pool on one of those techniques, you already have a job on the list, and that job means moving data: the longer you wait, the more data there is to move.

What happens to the cluster when you flip it

The flag can be enabled on pools that already exist — that is good news — and it can also be made the default for new pools through the central configuration option osd_pool_default_flag_ec_optimizations. What is not free is the moment you flip it.

The Proxmox documentation describes the side effect with welcome precision: Fast EC marks data shards 1 through k-1 as non-primary, so placement groups whose primary sat on one of those shards will re-peer; and that re-peering cancels any in-flight scrub, so those PGs will need to be scrubbed again afterwards.

Translated into what it means on an ordinary Tuesday: there is a burst of movement in the cluster, the scrub window slips, and during that spell your tolerance for losing a node is thinner than usual. It is a maintenance window, not a checkbox. You do it one pool at a time, with monitoring in front of you, and you let the cluster get back to HEALTH_OK before the next one.

Three cases where we would wait

• If your EC pool holds large objects. The Ceph team scopes it themselves: Fast EC is primarily intended to benefit block and file workloads, with possible benefits for S3 object workloads with small objects or random-access reads. A video or backup repository writing hundreds-of-megabytes objects sequentially is not the use case.
• If you are still on Squid. Then this is not your next job: the next one is the upgrade, and it deserves a calendar. Squid appears in Ceph's releases table, checked today, with an estimated end of life of 31 October 2026; we wrote at the time about the date on record back then, and the fact that it has shifted is exactly why these dates are called "estimated" and why you do not plan for the last day. And if your hypervisor is still on Proxmox VE 8, there is another clock running ahead of this one.
• If nobody is going to measure before and after. Flipping an irreversible switch with no baseline is faith, not engineering. Half an hour of fio with your workload's real pattern — not the one that looks good — is worth more than any chart in a release note, including the ones we have quoted here.

Architecture decisions with no minutes taken

We have been running Proxmox VE with Ceph in production for years, and the lesson that comes up most often has nothing to do with hardware. It is this: in a storage system, defaults are architecture decisions with no minutes taken. Nobody signed off on a 4K stripe_unit. Nobody argued in a meeting about whether the profile should be 2+2. It came out of the wizard that way, it worked, and years later it is still there deciding somebody's VM performance.

Fast EC is the first time in a long while that those defaults come back with a measurable bill. So before you plan the upgrade, pull each pool's profile with ceph osd erasure-code-profile get and note which of the three groups it falls into: the one that can flip the switch and get what the source promises, the one that can flip it and get "slightly less" because it is stuck on 4K, and the one that cannot flip it at all. All three are valid answers. What is not valid is not knowing and planning the window anyway.

If you want us to look at it with you — each pool's profile, whether the switch can be flipped, what you would actually gain with your workload and in what order — that is part of what we do in distributed storage with Ceph and in day-to-day support and operations.

Sources (verified on 7 August 2026): the four Fast EC optimisations (partial reads, no small-object padding, partial writes and parity delta writes, with three reads and three writes per strip at m=2), the figures ("at least double" the throughput on small writes, two to three times on small reads, "at least a doubling" on a mixed 70/30 workload at 16k comparing Squid at 4K with Tentacle at 16K), the test bench (one node, 8 NVMe OSDs, 2 × Intel Xeon Platinum 8276M at 2.20 GHz, 28 cores per socket), the stripe_unit statements (4K default, 16K recommended for new pools, impossible to change on existing ones) and the two sentences that qualify the headline — "three-way replica is still faster" and "with Erasure Code you get half the performance at less than half the cost" — come from Fast Erasure Coding for Tentacle on the official Ceph blog. The enablement conditions, the irreversibility of the flag ("once the flag has been enabled for a pool it cannot be disabled because it changes how new data is stored"), the requirement that all monitors and OSDs be on Tentacle, the restriction to the Jerasure and ISA-L plugins with the reed_sol_van technique, the BlueStore OSD requirement, the 16K-to-256K recommendation with its trade-off and the osd_pool_default_flag_ec_optimizations option are in the Ceph Tentacle erasure code documentation, which is also the source for the profile immutability sentence and the default profile (k=2, m=2, plugin=isa, technique=reed_sol_van); that the same page showed plugin=jerasure on Squid can be checked in its Squid version. That ISA-L is the default plugin is on the ISA plugin page; that jerasure "is no longer maintained and has not been updated to support modern CPU instructions", plus the technique list (reed_sol_van, reed_sol_r6_op, cauchy_orig, cauchy_good, liberation, blaum_roth, liber8tion), is on the jerasure plugin page. The deprecation note for techniques other than reed_sol_van and their removal in the Vampire release appears on the development version of that same page (docs.ceph.com/en/latest), not yet on the Tentacle one, and we have said so. The operational requirements on Proxmox (the four the monitor enforces, require_osd_release tentacle, the pool's -data suffix, the 4096-byte-multiple stripe_unit that the default already satisfies, the one-way switch and the re-peering that cancels scrubs) are in the Proxmox wiki, originating in the documentation patch sent to the pve-devel list on 16 April 2026. That Proxmox VE 9.2 ships Ceph Tentacle 20.2.1 by default with Squid 19.2.3 as an option comes from the release announcement. Release dates (Tentacle 20.2.0 on 18 November 2025, 20.2.1 on 6 April 2026, 20.2.2 on 16 June 2026 and 20.2.3 on 5 August 2026; Squid's estimated end of life on 31 October 2026) come from the Ceph releases table. We have not measured Fast EC on our own cluster: every number in this article is third-party and is cited as such. Social image photograph: rear of a rack at the NERSC data center, Wikimedia Commons, public domain (CC0).