# rados Published articles for rados. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## v20.2.2 Tentacle released DevFeed: [v20.2.2 Tentacle released]() Original publisher: [Read original article]() Author: Yuri Weinstein, Patrick Donnelly Published: 2026-06-16T00:00:00Z Content type: release Language: en Sources: [Ceph Blog]() Topics: [bug](), [Vulnerabilities](), [Memory Leaks](), [Encryption](), [configuration](), [IO]() Tags: [2026](), [aio](), [blog-post](), [bug](), [ceph](), [configuration](), [en-article](), [en-blog-post](), [encryption](), [io](), [memory-leaks](), [rados](), [release](), [rgw](), [storage](), [tentacle](), [ui](), [update](), [vulnerabilities]() ### AI overview Ceph v20.2.2 Tentacle is a minor release that adds Rocky 10 package-install support and recommends updating. It fixes issues across MDS, OSD, RGW, RADOS libraries, watch/notify operations, asynchronous utilities, and the dashboard, including security vulnerabilities, memory leaks, encrypted-object lifecycle problems, and UI and configuration improvements. ### Source excerpt This is the second minor release in the Tentacle series. We recommend that all users update to this release. Release Date ¶ June 16, 2026 Notable Changes ¶ Rocky 10 package-based installs are now supported starting with v20.2.2. Please see the supported platforms for current and planned support in Ceph. MDS (Metadata Server) ¶ Segmentation fault fixed due to incorrect queueing of request retries. OSD (Object Storage Daemon) ¶ PGLog Missed List: Fixed a bug to ensure the correct version is attached to the missing list when ignoring log entries. Data Integrity Asserts: Added assertions to explicitly catch potential corruption in the OSD missing list. RGW (RADOS Gateway) ¶ Lifecycle Management: Fixed lifecycle transition issues affecting encrypted multipart objects. REST & Query Handling: RESTArgs::get_string() now properly URL-decodes incoming query parameters. RADOS / librados / neorados ¶ Linger Operations: Rewrote safety checks to eliminate use-after-free vulnerabilities and LingerOp memory leaks when an unwatch operation returns ENOTCONN. Replaced the flawed is_valid_watch() check with a safe linger_by_cookie() lookup which safely manages LingerOp references using intrusive_ptr. Ensured librados linger callbacks hold a persistent reference to LingerOp to protect against races with simultaneous linger_cancel() requests. Configured librados::IoCtxImpl::aio_unwatch() to asynchronously deliver ENOTCONN to AioCompletion instead of returning the error directly. Watch/Notify: Fixed neorados notification queue bounds enforcement so that an overflow marker is only appended on the first message exceeding capacity, rather than duplicating it on every subsequent message. Prevented double-cleanup triggers in watch/notify operations when incoming errors arrive after maybe_cleanup() runs. Fixed a bug where notify would lose original error values by ensuring it no longer attempts to decode empty responses. Enhanced io_context shutdown procedures to clear handlers and route cleanl ## For whom the door-bell tolls DevFeed: [For whom the door-bell tolls]() Original publisher: [Read original article]() Author: Kyle Bader Published: 2026-06-11T00:00:00Z Content type: article Language: en Sources: [Ceph Blog]() Topics: [Caching](), [Large Language Model](), [Inference Performance](), [Low-Latency Inference](), [GPU](), [cpu]() Tags: [2025](), [ai](), [architecture](), [blog-post](), [cache](), [caching](), [ceph](), [cpu](), [en-article](), [en-blog-post](), [gpu](), [gpu-initated](), [inference](), [llm](), [nvme](), [rados](), [rados-nkv](), [storage]() ### AI overview The article explores using Ceph RADOS through NVMe key-value commands to support GPU-initiated storage access for LLM KV caching. It connects content-addressable caching with the efficiency of GPU-initiated NVMe access and discusses a possible vendor-specific extension for executing classes against objects. ### Source excerpt For whom the door-bell tolls In a previous post we extolled the benefits of KV caching, a technique to save the KV states from the prefill step of LLM-based inference to reduce time to first token (TTFT) and skip redundant computation. I co-presented this with Tushar Gohad at Cephalocon. Since then I've been thinking a lot about how to improve the state of the art. Really move the needle. We've made strides in a lot of areas in Ceph, especially the work going into Fast EC -- if you don't know what I'm talking about you should check it out, it promises huge benefits to a large category of workloads. That's not what we're here for today, though. Last year there was one paper that stuck in my mind, which is fairly remarkable because I read on the order of 130. That paper was GPU-Initiated On-Demand High-Throughput Storage Access in the BaM System Architecture. I struggled with this. It describes a system where a CPU loads a kernel into the GPU that allows the GPU to serve as an NVMe initiator. The struggle was rooted in the fact that block just felt like the wrong interface for KV caching. If you use block, then you need a lookup table that maps the hash of the sequences representing a cache block to a particular (device, offset, length) tuple. It begs for a content-addressable approach with no centralized lookup or coordination. On the other hand, what was described in the paper was just flat-out more electrically efficient. I couldn't have my cake and eat it too. The idea: RADOS, spoken as NVMe key-value ¶ In 2025 we also saw the first ratified version of the NVMe key-value command set specification. We already have a Ceph implementation of NVMe/TCP that leverages SPDK, and it seemed like we could add support fairly easily for the key-value command set. For those who don't know the internal mechanics of Ceph, the native API operates against RADOS objects. RADOS is richer than most object stores: it supports reads and writes to arbitrary offsets, deletes, key-value sto ## Managing Multiple Lua Scripts with Ceph Object Storage DevFeed: [Managing Multiple Lua Scripts with Ceph Object Storage]() Original publisher: [Read original article]() Author: Kirby Chin Published: 2026-06-10T00:00:00Z Content type: article Language: en Sources: [Ceph Blog]() Topics: [Lua](), [Script](), [Scripting](), [Security](), [Command-line interface](), [cloud-infrastructure](), [ransomware]() Tags: [availability](), [blog](), [blog-post](), [ceph](), [cli](), [data](), [developer](), [en-article](), [en-blog-post](), [examples](), [feature](), [go](), [lua](), [management](), [new-feature](), [object-storage](), [operations](), [rados](), [ransomware](), [rgw](), [s3](), [scripting](), [security](), [storage]() ### AI overview This article introduces a Ceph RADOS Gateway feature for managing multiple Lua scripts within the same request context and tenant. It demonstrates scripts for enforcing bucket object locks to mitigate ransomware risks and for optimizing storage through object auto-tiering. ### Source excerpt Since the Pacific release, Lua scripting in Ceph's RADOS Gateway (RGW) has provided users the ability to interpolate a single script to upload operations per request context and tenant. This way of working might be completely fine for a storage deployment with limited scripting customizations. However, script management becomes increasingly difficult as more than one team wants to get involved in managing the Lua script within the same context and tenant. For this reason, we've released a new feature in RGW allowing you to manage more than one Lua script at a time. In this blog, we'll go over a couple of examples to walk you through how this feature can help your team to reduce runtime errors and lower developer friction when managing Lua scripts in RGW. To begin, we will create a script to enforce a bucket security control and then add another script to demonstrate the new feature. Script 1: Bucket security ¶ Let's suppose we are part of a security team and want to mitigate the risk of ransomware threats happening on our storage platform. One possible way to achieve this is to implement a Write Once, Read Many (WORM) strategy to add an object lock onto any newly created bucket. By using an object lock, we can add a constraint to write objects to disk only once, ensuring that an infected client cannot delete or override objects at a later time. To set our WORM strategy, we can create a Lua script in the prerequest context that aborts when a create_bucket operation is made without the write-once (object lock) requirement. objectlock.lua -- enforcing object lock on bucket creation if Request.RGWOp == "create_bucket" and Request.HTTP.Metadata["x-amz-bucket-object-lock-enabled"] ~= "true" then RGWDebugLog("object lock is missing on bucket: " .. Request.Bucket.Name) Request.Response.Message = "Bucket must have object lock enabled" return RGW_ABORT_REQUEST end You can create a new objectlock.lua file with the contents above and run the CLI commands below to upload the scr ## RocksDB Compression in Ceph: Space Savings with No Performance Cost DevFeed: [RocksDB Compression in Ceph: Space Savings with No Performance Cost]() Original publisher: [Read original article]() Author: Daniel Alexander Parkes, Anthony D'Atri Published: 2025-12-17T00:00:00Z Content type: article Language: en Sources: [Ceph Blog]() Topics: [Compression](), [Database](), [Hardware](), [ibm]() Tags: [blog-post](), [ceph](), [compression](), [configuration](), [cost](), [devices](), [en-article](), [en-blog-post](), [ibm](), [mon](), [nvme](), [osd](), [performance](), [rados](), [reef](), [rocksdb](), [space](), [storage]() ### AI overview This article reports Ceph performance tests showing that enabling RocksDB compression can substantially reduce metadata database space, especially for smaller objects, without harming throughput or resource consumption. The tests used IBM Storage Ceph 7.1 with BlueStore OSDs, HDD object storage, and NVMe devices for the RocksDB WAL and database. ### Source excerpt Introduction ¶ In the world of data storage, engineers and architects constantly face a fundamental dilemma: the trade-off between performance and efficiency. It's a balancing act. When you want to save space, you typically enable features like compression, but the common assumption is that this will cost you performance, a CPU cycle tax that slows throughput. But what if you could significantly reduce your metadata storage footprint without slowing things down? This search for an answer to this question started with research work from Mark Nelson, who published a blog post on ceph.io that covers RocksDB tuning in depth, exploring RocksDB compression with positive results. These promising results sparked a conversation on the upstream GitHub about enabling compression by default; a link to the PR is available here. To build on the previous investigation, the Ceph performance team ran tests on a robust hardware configuration running IBM Storage Ceph 7.1 (Reef). The cluster used the BlueStore OSDs for an erasure-coded (EC 4+2) pool, with a hybrid OSD storage setup: HDDs for object data and fast NVMe drives for the BlueStore WAL+DB. To understand the test, it's helpful to know what the WAL+DB is. In modern Ceph, the BlueStore storage engine manages all data on the OSDs (physical devices). To do this, it must maintain a vast catalog of internal metadata: think of it as a high-speed index that quickly locates every piece of data. RocksDB, a high-performance key-value database, manages this critical index. In our hybrid cluster, the RocksDB database runs on the fast NVMe deviceses, while the actual object data resides on the slower HDDs. Because this metadata can grow very large, RocksDB's efficiency, how much space it consumes on those expensive NVMe drives, is a critical factor in the cluster's overall cost and performance. Our test, therefore, focuses on a simple, high-stakes question: Can we compress this metadata to save space without paying a performance penalty? Ex ## Object Storage Use Cases Part 3: Storing binary files in Object Storage instead of in your git repository DevFeed: [Object Storage Use Cases Part 3: Storing binary files in Object Storage instead of in your git repository]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2019-04-29T09:06:00Z Content type: tutorial Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [Git](), [ceph](), [pip](), [Haskell]() Tags: [aws](), [ceph](), [data](), [data-lake](), [git](), [install](), [object-storage](), [python](), [rados](), [radosgw](), [s3](), [storage]() ### AI overview This post explains why binary files should not be stored directly in Git repositories and explores using CSC's Pouta Cloud Object Storage instead. It documents attempts with git-annex and git-bigstore, including a patch to configure a non-default S3-compatible endpoint. ### Source excerpt 1. It's bad to store binary blobs in git. This is known [1] 2. A great place to store binary files is in object storage 3. Can we use CSC's Pouta Cloud Object Storage service for this? Why yes, yes you can! This is a post in a series about different use cases for object storage. Others include for example hosting a reveal.js presentation and NFS server backups More details about CSC's Pouta Cloud Object Storage Service, it is based on CEPH Rados Object Storage Gateway. What The general solution* to storing binaries in git is to not store them in git and instead create a link to some other place Attempt 1 Install an application that you like. In https://www.perforce.com/blog/storing-large-binary-files-in-git-repositories I searched for "S3", found git-annex which had recent commits so it looked like it wasn't dead. Installation instructions: https://git-annex.branchable.com/install/ The version in EPEL/Ubuntu Xenial does not have S3 support and is from 2014. There's a recent one in Fedora's repos though. Unfortunately, compiling it requires cabal. I don't know Haskell. https://spack.readthedocs.io/en/latest/package_list.html does not have any Haskell, cabal or git-annex available. Next. Attempt 2 Next application in the blog post was https://github.com/lionheart/git-bigstore To install it was much more comfortable for me: pip install "git-bigstore<=2.0" First issue was that looking at https://github.com/lionheart/git-bigstore/blob/master/bigstore/backends/s3.py there was no way to tell it to use another endpoint than the default of AWS S3. A small patch takes care of that, add , endpoint_url='https://object.pouta.csc.fi:443' to the client() boto3 call in the backends/s3.py file from git-bigstore. For a more detailed example see this Pull Request. After spending some time going down some rabbit holes it seems that the Profile option that is supported in git-bigstore does not support endpoints. It can only be used to specify credentials and a few other parameters. Mino ## Admin Stories: Implement Object Storage in CSC's cPouta DevFeed: [Admin Stories: Implement Object Storage in CSC's cPouta]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2018-02-12T12:58:00Z Content type: article Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [ceph](), [Amazon S3](), [Cloud](), [API]() Tags: [backend](), [ceph](), [cpouta](), [infrastructure](), [object](), [object-storage](), [openstack](), [rados](), [radosgw](), [rgw](), [s3](), [server](), [servers](), [storage](), [volume]() ### AI overview This article explains the decisions behind implementing object storage in CSC's cPouta cloud. It describes using Ceph RADOS Gateway with existing Ceph clusters and clarifies the relationship between S3 buckets, Swift containers, accounts, and OpenStack project IDs. ### Source excerpt In our previous user survey we found out that you were interested in "OpenStack admin stories". This will be our first attempt in doing that. User guide: https://research.csc.fi/pouta-user-guide While implementing object storage we made a few decisions. This blog post is about highlighting the decisions and their backing thought process. Some background information: cPouta uses OpenStack as the underlying cloud middleware, and Ceph for storing volumes and images. And going forward, objects, too. Terminology RADOS Gateway/RadosGW/RGW/Ceph RGW/Ceph radosgw/radosgw. We mean the same thing. It's a piece of software which exposes an API for storing and retrieving objects. Ceph - the storage system which RadosGW daemons access as a client. Buckets in S3 and Containers in Swift are synonymous. The Ceph radosgw-admin tool also operates on buckets. The latter are mostly the same, but can contain a bit more information i.e. OpenStack project ID. If we write about buckets, the reader can presume we are referring to S3 buckets and Swift containers unless otherwise noted. Account is something that RGW binds usage data into. In some of the radosgw-admin CLI calls, accounts are referred to as users or UIDs. These users and/or accounts get a mapping to OpenStack project IDs in our configuration. So be it account/user/project, we are always talking about the same thing. - Why Ceph RadosGW The other option we briefly looked at for an Object Storage server was the OpenStack Swift server. Yes, there is an API called Swift and a piece of sofware called Swift which serves the Swift API. Not to mention the programming language Swift, the ISO standard SWIFT or the Scottish potato variant Swift. In the end we used none of these for backend because we prefer to reuse existing infrastructure. We already have Ceph clusters used for Virtual Machine image and block (volume) storage in our clouds. Installing some Ceph RadosGW servers and pointing those to an existing Ceph cluster utilizes a lot o