# Assessing the performance of the CLAY Erasure Code Plugin

DevFeed: [Assessing the performance of the CLAY Erasure Code Plugin](<https://devfeed.tech/articles/assessing-the-performance-of-the-clay-erasure-code-plugin-12326.md>)

Original publisher: [Read original article](<https://ceph.io/en/news/blog/2025/cbt-performance-benchmarking-part4/>)

Author: Jake Squelch (IBM)

Published: 2026-02-11T00:00:00Z

Content type: article

Language: en

Sources: [Ceph Blog](<https://devfeed.tech/sources/ceph-blog.md>)

Topics: [benchmarking](<https://devfeed.tech/topics/benchmarking.md>), [IO](<https://devfeed.tech/topics/io.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [4k](<https://devfeed.tech/tags/4k.md>), [benchmark](<https://devfeed.tech/tags/benchmark.md>), [benchmarking](<https://devfeed.tech/tags/benchmarking.md>), [benchmarks](<https://devfeed.tech/tags/benchmarks.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [ceph](<https://devfeed.tech/tags/ceph.md>), [en-article](<https://devfeed.tech/tags/en-article.md>), [en-blog-post](<https://devfeed.tech/tags/en-blog-post.md>), [io](<https://devfeed.tech/tags/io.md>), [performance](<https://devfeed.tech/tags/performance.md>)

## AI overview

This article assesses the performance of the CLAY Erasure Code Plugin using CBT benchmarks. It reports that CLAY and JErasure have practically identical read performance for 4K random reads and 1024K sequential reads, while CLAY has substantially lower write performance, especially at higher bandwidths. The article attributes this to CLAY's more complex encoding process, which performs two encoding stages plus an additional memory copy. It also reports worse performance with an OSD down, including increased latency for degraded reads, but the supplied text ends before the discussion is complete.

## Source excerpt

CBT Performance Benchmarking - Part 4. What can we say about CLAY? Outline of the Blog Series ¶ Part 1 - How to start a Ceph cluster for a performance benchmark with CBT Part 2 - Defining YAML contents Part 3 - How to start a CBT performance benchmark Part 4 - Assessing the performance of the CLAY erasure code plugin Contents: Client IO results for CLAY Client IO with an OSD down What is CLAY good at? Problems with using CLAY How does CLAY read data from the drive? CLAY is broken in tentacle Summary Client IO results for CLAY ¶ As a refresher lets quickly look back on the client IO results of CLAY compared to JErasure: If we look back to Step 3 in Part 3 of the blog (Generating a comparison report), we saw that reads had practically identical curves between CLAY & JErasure for both 4K random reads and 1024K sequential reads. However, when we compared writes we saw that the performance hit to CLAY was substantially larger, particularly for higher bandwidths. The 1024k Sequential Writes diagram represents this: Click to see Part 3 diagrams So why was this? This is because of CLAY's encoding process, it is significantly more complex. While JErasure performs a single encoding pass, CLAY uses three phases: 50% of data is encoded using PRT (Product Recovery Transform), 50% of the data is copied to form an intermediate set of buffers All the intermediate data is encoded using RS (Reed-Solomon) to form a second set of intermediate buffers 50% of the result is encoded using PFT (Parity Fractional Transform), 50% of the data is copied to form the output buffers Essentially, CLAY performs 2x the encoding plus an additional memcpy (memory copy) compared to JErasure's 1x encoding. This overhead therefore directly translates to lower write throughput for CLAY, as shown by the diagrams above. The performance impact increases for larger IO sizes because more data is being encoded. Referenced the following: 'Clay Codes: Moulding MDS Codes to Yield an MSR Code' above for information