# IO Published articles for IO. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Performance improvements in Percona Server 8.4.11-11 DevFeed: [Performance improvements in Percona Server 8.4.11-11]() Original publisher: [Read original article]() Author: Bogdan Degtyariov Published: 2026-09-15T11:52:54Z Content type: article Language: en Sources: [Blog - Percona]() Topics: [Percona Server for MySQL](), [Percona](), [MySQL](), [Cache](), [Scalability](), [Database]() Tags: [benchmark](), [benchmarks](), [cache](), [io](), [mysql](), [percona](), [percona-server-for-mysql](), [performance](), [scalability]() ### AI overview This article describes performance and scalability improvements in Percona Server for MySQL 8.4.11-11, focusing on changes to the InnoDB buffer pool and page flushing. It explains how narrowing mutex coverage and using finer-grained latching allows physical reads to proceed more in parallel, particularly for read-heavy, I/O-bound workloads. ### Source excerpt Focusing on Percona Server 8.4.11-11 My previous post (Performance Progression of Percona Server for MySQL 8.4) did a brief review of the performance changes in Percona Server for MySQL 8.4 released in 2026. I recommend reading it first to better understand the material in this post. Version 8.4.11-11 includes patches that deliver significant improvements in ... Continued The post Performance improvements in Percona Server 8.4.11-11 appeared first on Percona. ## M5Stack Module13.2 LoRa-1262 expansion board integrates 14x10 mm Stamp LoRa-1262 module DevFeed: [M5Stack Module13.2 LoRa-1262 expansion board integrates 14x10 mm Stamp LoRa-1262 module]() Original publisher: [Read original article]() Author: Debashis Das Published: 2026-09-13T05:02:54Z Content type: news Language: en Sources: [CNX Software - Embedded Systems News]() Topics: [lora](), [systems]() Tags: [connectivity](), [development-board](), [embedded-systems](), [hardware](), [i2c](), [io](), [iot](), [lora](), [lorawan](), [low-power](), [lpwan](), [m5stack](), [module](), [news](), [power-management](), [routing](), [series](), [smart-agriculture](), [smart-city](), [spi](), [wireless]() ### AI overview M5Stack has launched the Stamp LoRa-1262 SMD module and the stackable Module13.2 LoRa-1262 expansion board for M5Stack Core controllers. Based on the Semtech SX1262, the module supports several modulation modes across 868-923 MHz, with up to +22 dBm transmit power and -147 dBm receive sensitivity. Module13.2 adds an RP-SMA antenna interface, M5IOE1 I/O expansion, configurable pin routing, and selectable I2C addresses for multi-module stacking. ### Source excerpt After launching the SX1262-based M5Stamp C6LoRa tiny module, M5Stack has launched two SX1262-based LoRa add-ons for the 868-923 MHz band: the tiny Stamp LoRa-1262 SMD module for custom PCBs, and the stackable Module13.2 LoRa-1262 module for the M5Stack Core series. The Stamp LoRa-1262 supports LoRa, FSK, GFSK, MSK, GMSK, and OOK modulation, with up to +22 dBm transmit power and -147 dBm receive sensitivity. The Module13.2 adds an RP-SMA antenna interface, an M5IOE1 IO expansion chip for reset and power management, and DIP switches for flexible pin routing and configurable I2C addresses, enabling multi-module stacking. Stamp LoRa-1262 SMD module M5Stack Stamp LoRa-1262 specifications: LoRa Transceiver - Semtech SX1262 Wireless Connectivity (LoRa) Frequency Band - 868 to 923 MHz Modulation Modes - LoRa, FSK, GFSK, MSK, GMSK, OOK Bitrate - Up to 300 kbps (programmable) Transmit power (Tx) - Up to +22 dBm Receive sensitivity (Rx) - Down to -147 dBm [...] The post M5Stack Module13.2 LoRa-1262 expansion board integrates 14x10 mm Stamp LoRa-1262 module appeared first on CNX Software - Embedded Systems News. ## Linux's IO\_uring Sees Some "Crazy" Patches That Deliver Very Nice Improvements DevFeed: [Linux's IO\_uring Sees Some "Crazy" Patches That Deliver Very Nice Improvements]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-11T16:21:33Z Content type: news Language: en Sources: [Phoronix]() Topics: [io\_uring](), [Linux](), [IO]() Tags: [desktop-linux](), [developer](), [io](), [io-uring](), [kernel](), [linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [ubuntu-benchmarks](), [ubuntu-hardware]() ### AI overview Linux io_uring patches proposed by Jens Axboe aim to improve blocking behavior and reduce unnecessary thread wakeups, context switches, and task-work completion overhead. Requests would run inline in blocking mode and offload only when they actually block, while preserving the submitting task's user-visible identity. ### Source excerpt Linux block subsystem maintainer and IO_uring lead developer Jens Axboe continues to uncover new opportunities for making the wonderful IO_uring framework even more performant within the Linux kernel. For ending out the week he's posted some "crazy" patches delivering some significant gains... ## Compute that takes any shape DevFeed: [Compute that takes any shape]() Original publisher: [Read original article]() Author: Luke Phillips-Sheard Published: 2026-09-01T07:00:00Z Content type: article Language: en Sources: [Vercel News]() Topics: [Cloud](), [Provisioning](), [cloud-infrastructure](), [Vercel](), [cpu](), [IO](), [DRIVE]() Tags: [agent](), [cloud](), [code](), [compute](), [cpu](), [image](), [infrastructure](), [io](), [memory](), [pricing](), [real-time](), [sandbox](), [storage](), [vercel]() ### AI overview Vercel presents Fluid as a unified compute system that assembles machines for different workloads, changes configuration dynamically, and absorbs burst capacity in real time. It supports builds, sandboxes, and functions, using isolated virtual machines, custom images, and separate storage connections. ### Source excerpt Workloads differ in how long they run, how much memory they take, and how much of the environment they control. That previously meant a different compute primitive for each job, so product iterations required provisioning infrastructure, not just working on a feature. We built Vercel so that none of this has to be your problem. The compute layer is a single system with a simple job. Take any workload, assemble the machine it needs, swap configuration on the fly, and absorb burst capacity in real time. We call this Fluid. Builds ran on it first, then sandboxes, and now functions. If you've shipped on Vercel, you've been on Fluid without knowing it. Fluid compute now runs over 15 million builds a day, 25 million sandboxes a week, and a trillion requests a month. A history of compute Changing a machine used to mean changing it by hand. You went down to the computer store, bought a hard drive or a stick of RAM, and swapped it in yourself. Then you could rent bare metal when you needed it, and use it to serve a website, host a database, or send email. Then the cloud let you request a machine in any configuration you wanted, choose its operating system, use it, and throw it away when you were done. For agents, even the cloud is too slow. A standard VM can't provision fast enough to keep up with how they work, but this is where Fluid excels. How a workload runs on Fluid When a workload comes in, Fluid assembles a machine to fit its shape. If an agent needs to run code, Hive provides an isolated VM, usually one already warm, so it's ready instantly. Your own image boots on top as the environment. A Drive connects, and your files are right where you left them, because storage was never tied to the machine. Each workload needs something different. A build is compute-bound, so it wants a beefy machine, heavy on CPU and memory. A function is IO-bound, loading specific code to run the instant a request lands, usually on a small VM. A sandbox is flexibility-bound, taking whatever ## 【etcd】Watch 机制：watchableStore、synced/unsynced 与 ErrCompacted DevFeed: [【etcd】Watch 机制：watchableStore、synced/unsynced 与 ErrCompacted]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [Remote Procedure Call (RPC)](), [Kubernetes]() Tags: [apiserver](), [apply](), [compaction](), [distributed](), [errcompacted](), [etcd](), [io](), [k8s](), [kubernetes](), [lag](), [leader](), [lease](), [mvcc](), [notify](), [raft](), [range](), [restore](), [revision](), [rpc](), [v3-5](), [v3-5-33](), [watch](), [watchablestore]() ### AI overview This article examines the etcd v3.5.33 watchableStore implementation, including synced and unsynced watcher groups, victims caused by backpressure, Apply-time notification, historical synchronization, and the ErrCompacted client resynchronization boundary. It also discusses event ordering, follower watch progress, and interactions with Kubernetes apiserver watch caches. ### Source excerpt 钉 etcd v3.5.33 watchableStore 的 synced/unsynced/victims 三分法、Apply 后 notify 与历史追赶 syncWatchersLoop，以及 CompactRevision 触发 ErrCompacted 时的客户端重同步边界。 ## Hot Chips 2026: Intel's Diamond Rapids DevFeed: [Hot Chips 2026: Intel's Diamond Rapids]() Original publisher: [Read original article]() Author: George Cozma Published: 2026-08-25T06:20:03Z Content type: article Language: en Sources: [Chips and Cheese]() Topics: [cpu](), [intel](), [Cache](), [IO](), [x86]() Tags: [2026](), [cache](), [cpu](), [intel](), [io](), [processor](), [x86]() ### AI overview The article examines Intel's Diamond Rapids server CPU, including its 3D-stacked L3 cache, die and packaging design, revised 256-core specification, 1.6 TB/s memory bandwidth, 128 PCIe Gen 6 lanes, and two new x86 ISA extensions. It compares these characteristics with AMD's Venice processor. ### Source excerpt Hello you fine Internet folks, ## Native Async/Coroutine Reads in RocksDB DevFeed: [Native Async/Coroutine Reads in RocksDB]() Original publisher: [Read original article]() Author: Josh Kang Published: 2026-08-24T00:00:00Z Content type: release Language: en Sources: [RocksDB]() Topics: [rocksdb](), [Coroutines](), [C++](), [IO](), [API]() Tags: [async](), [asynchronous](), [blog](), [c-plus-plus](), [coroutine](), [io](), [native](), [rocksdb](), [thread]() ### AI overview RocksDB introduces experimental asynchronous Get and MultiGet APIs backed by native C++ coroutines. The APIs can suspend storage-bound reads, allowing a small executor to run other ready tasks and maintain more storage queue depth without one blocked application thread per read. The feature targets throughput for I/O-bound point lookups rather than reducing individual device-read latency. ### Source excerpt A point lookup that misses RocksDB's block cache can spend most of its time waiting for storage. The traditional way to keep more reads in flight is to add threads. That works, but each outstanding read parks a thread, carries a stack, and adds context-switching overhead. RocksDB now has experimental asynchronous Get and MultiGet APIs backed by native C++ coroutines. When a read reaches storage, RocksDB can suspend the request, let its read-executor worker run another ready task, and resume the request when the filesystem reports completion. A small executor can therefore maintain more storage queue depth without requiring one blocked application thread per read. These APIs are available in RocksDB 11.10.0. This is primarily a throughput feature for I/O-bound point lookups. It does not make an individual device read faster. Its benefit comes from keeping the device busy and using CPU threads for runnable work. The API surface RocksDB exposes the new read path through two public interfaces: DB::GetAsync and DB::MultiGetAsync return immediately on the native path and report completion through AsyncCallback::OnComplete. CoroDB::CoGet and CoroDB::CoMultiGet return lazy folly::coro::Task objects. CoGet produces a Status; CoMultiGet fills the same per-key values and statuses as synchronous MultiGet. The callback APIs suit applications that do not expose Folly tasks at their boundaries. The CoroDB APIs let coroutine-based callers await RocksDB directly, avoiding an application-side callback-to-Baton adapter and its extra completion handoff. Native execution requires RocksDB to be built with Folly and USE_COROUTINES=1. Neither interface requires ReadOptions::async_io. That flag continues to control the older internal async-I/O optimizations for synchronous MultiGet and iterators. The task APIs are lazy: no read begins until a task is awaited or started. Both interfaces take pointer and reference parameters, so keep the DB, column-family handles, ReadOptions, keys and their ## Podman Container Tools Grows DevFeed: [Podman Container Tools Grows]() Original publisher: [Read original article]() Author: mheon Published: 2026-08-10T18:18:27Z Content type: article Language: en Sources: [blog.podman.io]() Topics: [podman](), [Buildah](), [Skopeo](), [GitHub](), [Cloud Native Ecosystem]() Tags: [api](), [buildah](), [ci](), [cloud-native](), [cncf](), [github](), [images](), [io](), [podman](), [podman-machine](), [python](), [releases](), [signing](), [skopeo](), [storage](), [uncategorized]() ### AI overview The Podman 6.0 release moves Podman, Buildah, and Skopeo into a new GitHub organization owned by the Cloud Native Computing Foundation. Additional repositories, including podman-machine-os and container-libs, are joining the project, while further moves for podman-py, project websites, utility repositories, Netavark, and Aardvark-dns are planned or under consideration. ### Source excerpt As part of the Podman 6.0 release, we've moved Podman, Buildah, and Skopeo into a new GitHub organization owned by the Cloud Native Computing Foundation (CNCF). For most people, the most visible part of this is that the old repositories in the github.com/containers organization now redirect to https://github.com/podman-container-tools, but we've also made some other changes [...] ## v20.2.3 Tentacle released DevFeed: [v20.2.3 Tentacle released]() Original publisher: [Read original article]() Author: Yuri Weinstein Published: 2026-08-05T00:00:00Z Content type: release Language: en Sources: [Ceph Blog]() Topics: [Deployment](), [Server](), [Hardware](), [TLS (Transport Layer Security)](), [Kafka](), [Grafana Cloud Metrics](), [Monitoring](), [Command-line interface](), [IO]() Tags: [2026](), [authentication](), [blog-post](), [cli](), [en-article](), [en-blog-post](), [hardware](), [io](), [kafka](), [metrics](), [monitoring](), [release](), [storage](), [tentacle](), [tls]() ### AI overview Ceph v20.2.3, the third minor release in the Tentacle series, is a recommended update containing fixes and improvements across metadata servers, object storage daemons, RADOS Gateway, client libraries, the dashboard, ceph-volume, and NVMe-oF. Changes include storage reliability fixes, TLS 1.3 cipher customization, encrypted object copying, Kafka notification authentication, hardware monitoring, CSV host uploads, and role-management updates. ### Source excerpt This is the third minor release in the Tentacle series. We recommend that all users update to this release. Release Date ¶ August 5, 2026 Notable Changes ¶ MDS (Metadata Server) ¶ Fixed a crash and shutdown hang that could occur when ephemeral pins were active and max_mds was set to 0. Session reclaim could miss blocklisting an old session; this is now handled correctly. Fixed a case where scrub was unable to identify damage from an irreparable hard link. OSD (Object Storage Daemon) ¶ BlueStore: Fixed a BlueFS WAL envelope-mode bug that caused write buffer misalignment. Erasure Coding: Fixed truncate+write planning for EC shard sizes. Fixed a condition that prevented rolling forward of PG log entries. Prevented OSDMap::check_health() from asserting when new OSDs are found in a subtree. Scrub: "repairing" scrubs -- deep scrubs re-run specifically to fix a previously detected inconsistency -- are no longer blocked by the configured allowed scrub hours/days; they can now run at any time. RGW (RADOS Gateway) ¶ Added the ssl_ciphersuites option for the Beast front-end to support TLS 1.3 cipher customization. Fixed PutObject's canned_acl comparison bug affecting BlockPublicAcls. Fixed crashes occurring on realm reload. Implemented CopyObject support for encrypted objects. Added mTLS client-certificate authentication support for Kafka notifications. Fixed removal of delete markers in lifecycle processing. RADOS / librados / neorados ¶ neorados: Fixed an infinite trim loop on empty data log shards. Fixed cancellation-slot cleanup in librados/asio's associated executor. Dashboard ¶ Added a hardware-monitoring dashboard backed by node-proxy metrics. Fixed a bind-address regression caused by CherryPy isolation. Added support for adding hosts via CSV upload. NVMeoF: multiple CLI and UI backports (EC pool support, IO statistics, role management). Object: The global RGW Roles tab has been removed. Role management is now scoped under RGW Accounts, where roles can be listed, created, ## Postgres backups under the hood DevFeed: [Postgres backups under the hood]() Original publisher: [Read original article]() Author: Josh Brown Published: 2026-07-24T00:00:00Z Content type: article Language: en Sources: [Blog -- PlanetScale]() Topics: [Databases](), [data](), [SQL](), [IO](), [Filesystems]() Tags: [backup](), [data](), [database](), [engineering](), [how-to](), [io](), [postgres](), [recovery](), [sql]() ### AI overview This article explains how Postgres backups work, focusing on logical backups and their tradeoffs. It describes consistent snapshots, SQL or custom output formats, resource costs at large data volumes, the lack of point-in-time recovery, and the use of MVCC for online backups. ### Source excerpt With backups being such a vital part of keeping your data safe, how do they actually work? ## libosmocore - libosmocore 1.14.1 released DevFeed: [libosmocore - libosmocore 1.14.1 released]() Original publisher: [Read original article]() Author: osmith Published: 2026-07-22T10:37:33Z Content type: release Language: en Sources: [Open Source Mobile Communications: News]() Topics: [changelog](), [IO](), [cpu](), [scheduling](), [make]() Tags: [2026](), [bug](), [changelog](), [cpu](), [io](), [issue](), [make](), [scheduling](), [tracker]() ### AI overview libosmocore 1.14.1 has been released with fixes to I/O queue handling, CPU scheduling initialization and platform-dependent scheduling support, utility issues, and a missing crypto header in the build configuration. ### Source excerpt Today we've released libosmocore 1.14.1. The changelog over 1.14.0 is as follows: libosmocore (1.14.1) unstable; urgency=medium [ Vadim Yanitskiy ] * osmo_io: iofd_txqueue_dequeue(): fix double next->io_len decrement [ Timur Davydov ] * vty: fix osmo_cpu_sched_vty_init() prototype * vty: make CPU scheduling optional based on platform support [ Oliver Smith ] * utils: fix typos * utils/gsmtap-logsend: close infile before exit [ Alexander Couzens ] * gsm/Makefile.am: add missing kdf/crypto.h -- Oliver Smith Wed, 22 Jul 2026 11:30:55 +0200 ## Mastering Linux Administration: 20 Powerful Commands to Know DevFeed: [Mastering Linux Administration: 20 Powerful Commands to Know]() Original publisher: [Read original article]() Author: Hayden James Published: 2026-07-06T03:56:38Z Content type: tutorial Language: en Sources: [Hayden James]() Topics: [Linux](), [Command-line interface](), [Monitoring](), [Filesystems](), [IO](), [cpu]() Tags: [administration](), [automated](), [backup](), [blog](), [command-line](), [commands](), [cpu](), [examples](), [files](), [https-linuxblog-io-tag-commands](), [io](), [linux](), [memory](), [monitoring](), [ncurses](), [sysadmins]() ### AI overview A tutorial introducing 20 Linux commands for system administrators, with examples and explanations of their uses. The supplied text specifically discusses vmstat for monitoring system and memory statistics, inotifywait for tracking filesystem events, and ncdu for analyzing disk usage. ### Source excerpt Linux is a powerful and versatile operating system that can be used for a wide range of purposes. For many system administrators, the command line interface is the primary way to interact with the system. Continue reading... ## 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 ## Why You Should Tune Code Before Your Garbage Collector DevFeed: [Why You Should Tune Code Before Your Garbage Collector]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2026-06-08T11:52:44Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Benchmark](), [Java](), [Latency](), [Logging](), [Code]() Tags: [benchmark](), [benchmarks](), [io](), [java](), [latency](), [logging](), [low-latency](), [performance]() ### AI overview A Java latency benchmark compares garbage collectors while varying redundant SLF4J logging and log storage. The article reports that removing redundant logging can have a much larger effect on extreme tail latency than changing the garbage collector, and can change which collector performs best. ### Source excerpt Optimising your memory allocations in Java could make far more difference than your choice of Garbage Collector and may even change which is the best garbage collector. In this post I look at a simple event to response latency benchmark, MarketDataSnapshot to NewOrderSingle at 50K/s for 30 minutes using JLBH to test Chronicle-FIX. The goal is to compare a system which is doing redundant work (in this case logging each message using SLF4J), compared with not logging (Chronicle-FIX records every message internally using Chronicle Queue) and how this changes the choice of Garbage Collector For the p99 (worst 1 in 100) the choice of Garbage Collector makes a different on par with optimising how loggin is done However, for the p99.99 (worst 1 in 10,000) optimsing how the logging is done is orders of magnitude more signifciant than the choice of Garbage Collector Unoptimised Benchmark This takes the optimised benchmark and adds one SLF4J log line of just the message to be sent. One log line might not sound like much but ding this on every message makes a big difference esp when the rest of the code is written for low latency. Table 1. RTT latency distribution with slf4j logging GC option p99 p99.99 Parallel large Eden, no large pages 16.86 20,480 ZGC, no large pages 12.21 19,694 G1 + COH, no large pages 12.02 20,349 G1, 2 MiB large pages 13.94 20,021 Shenandoah generational, no large pages 12.30 19,235 Note The p99.99 are thousands of microseconds or 19 to 20 milliseconds. The p99.99 or worst 1 in 10,000 might sound rare, however at 50K/s that is 5 times per second or 300 times per minute Based on these results, you might conclude that Shenandoah is a good option, and avoid Parallel GC. How much difference is the disk IO making IO is often a significant proportion of delays, and we can see that just moving where the logs are written. In this case to a tmpfs filesystem. Table 2. RTT latency distribution with slf4j logging to /dev/shm GC option p99 p99.99 Parallel large Ede ## Hacking Workshop for June/July 2026 DevFeed: [Hacking Workshop for June/July 2026]() Original publisher: [Read original article]() Author: Robert Haas (noreply@blogger.com) Published: 2026-06-02T18:36:18Z Content type: news Language: en Sources: [Robert Haas]() Topics: [Hacking](), [PostgreSQL](), [IO](), [observability]() Tags: [2026](), [announce](), [hacking](), [io](), [mentoring](), [observability](), [postgresql](), [sessions](), [sign-up]() ### AI overview The June/July 2026 PostgreSQL Hacking Workshop will feature Melanie Plageman discussing her talk "Additional IO Observability in Postgres with pg_stat_io." Interested participants can sign up to receive an invitation. ### Source excerpt I was hoping to usual resume the monthly cadence of hacking workshops in June, but it didn't quite happen, largely due to being a little exhausted after pgconf.dev. But, I'm pleased to announce that Melanie Plageman will be joining us to discuss her talk Additional IO Observability in Postgres with pg_stat_io. If you're interesting in joining us, please sign up using this form and I will send you an invite to one of the sessions. As always, thanks to Melanie for joining us.Read more " ## Waiting for PostgreSQL 19 - Online enabling and disabling of data checksums DevFeed: [Waiting for PostgreSQL 19 - Online enabling and disabling of data checksums]() Original publisher: [Read original article]() Author: depesz Published: 2026-04-15T18:05:36Z Content type: article Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [postgresql clusters](), [async](), [IO]() Tags: [async](), [background](), [background-work](), [checksums](), [data-checksum](), [io](), [pg19](), [postgresql](), [uncategorized](), [vacuum](), [waiting]() ### AI overview This article examines a PostgreSQL 19 patch that allows data checksums to be enabled or disabled while a cluster is running. The command is immediate, but rewriting every table and index occurs in the background and can require substantial I/O. The article also discusses cost-delay options for controlling the background worker. ### Source excerpt On 3rd of April 2026, Daniel Gustafsson committed patch: Online enabling and disabling of data checksums This allows data checksums to be enabled, or disabled, in a running cluster without restricting access to the cluster during processing. Data checksums could prior to this only be enabled during initdb or when the cluster is ... Continue reading "Waiting for PostgreSQL 19 - Online enabling and disabling of data checksums" ## Per-worker, and global, IO bandwidth in explain plans DevFeed: [Per-worker, and global, IO bandwidth in explain plans]() Original publisher: [Read original article]() Author: depesz Published: 2026-02-21T13:24:57Z Content type: article Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [IO](), [parallel]() Tags: [analyze](), [execution](), [explain](), [explain-depesz-com](), [io](), [parallel](), [plan](), [postgresql](), [speed](), [timing](), [uncategorized](), [worker]() ### AI overview This article explains how PostgreSQL explain plans can report per-worker and global I/O bandwidth during parallel execution. It describes how summed worker timings differ from wall-clock time and introduces an exclusive-time bandwidth figure for the disks' total workload. ### Source excerpt Jeremy Schneider suggested a change to how plans are displayed - adding another bit of information in case we have timing information for IO for explain node. Took me a while to research, but it finally made it's way... Let's consider this simple plan. In it's Parallel Seq Scan node we see: -> Parallel Seq ... Continue reading "Per-worker, and global, IO bandwidth in explain plans" ## Assessing the performance of the CLAY Erasure Code Plugin DevFeed: [Assessing the performance of the CLAY Erasure Code Plugin]() Original publisher: [Read original article]() Author: Jake Squelch (IBM) Published: 2026-02-11T00:00:00Z Content type: article Language: en Sources: [Ceph Blog]() Topics: [benchmarking](), [IO](), [Code]() Tags: [4k](), [benchmark](), [benchmarking](), [benchmarks](), [blog-post](), [ceph](), [en-article](), [en-blog-post](), [io](), [performance]() ### 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 ## RGW Bucket Resharding Without Pausing DevFeed: [RGW Bucket Resharding Without Pausing]() Original publisher: [Read original article]() Author: Daniel Alexander Parkes, Anthony D'Atri Published: 2026-02-01T00:00:00Z Content type: article Language: en Sources: [Ceph Blog]() Topics: [systems](), [Scalability](), [Architecture & Design](), [cloud-infrastructure]() Tags: [2026](), [article](), [blog-post](), [ceph](), [concurrent](), [deep-dive](), [en-article](), [en-blog-post](), [io](), [operational](), [operations](), [performance](), [production](), [rgw](), [s3](), [scalability](), [scale](), [storage](), [systems]() ### AI overview The article explains how Ceph Tentacle introduces near-zero-impact RGW bucket resharding. Its two-phase architecture moves intensive work into a non-blocking background phase, avoiding the prolonged write unavailability and 504 errors seen in Ceph Squid and earlier versions. ### Source excerpt Introduction: The Foundation of Scalable Object Storage ¶ In the modern data landscape, object storage has evolved from a simple file repository into the foundational layer for AI/ML pipelines, data lakehouses, real-time analytics, and massive-scale archival systems. At the heart of this evolution is a deceptively simple question: How do you efficiently locate and access billions of objects stored in a single bucket? The answer lies in one of Ceph's most critical performance mechanisms: bucket index sharding. This architectural pattern divides a bucket's index into multiple parallel structures, enabling concurrent operations across thousands of objects while maintaining the consistency and reliability that enterprise workloads demand. But there's always been a catch. As workloads grow and evolve, buckets need to be resharded. Historically, when the buckets to be resharded had a vast number of objects, this operation came with a painful trade-off: blocking client writes from seconds to minutes, with a chance of causing application disruptions, 504 Gateway errors, and operational headaches. With Ceph Tentacle, we're eliminating this trade-off. The new near-zero impact bucket resharding architecture transforms what was once a maintenance window event into a seamless background operation that your applications will never notice. Note: As of 2026/02/05, the functionality described in this article is expected in an upcoming Tentacle update. Executive Summary ¶ The Challenge: In Ceph Squid, resharding a 20-million-object bucket blocked writes for 4+ minutes, returning 504 errors. Even larger buckets (500M objects) required 94 minutes of complete write unavailability. The Solution: Ceph Tentacle's two-phase architecture moves the heavy lifting to a non-blocking background phase, eliminating the impact on clients IO. The Results: (note: in this graphic 8.1 refers to Squid and 9.0 to Tentacle) In this deep dive, we'll explore: Why bucket sharding is essential for modern workl ## How io\_uring improves database performance DevFeed: [How io\_uring improves database performance]() Original publisher: [Read original article]() Published: 2025-12-11T00:00:00Z Content type: tutorial Language: en Sources: [Gaurav Sarma's Blog]() Topics: [io\_uring](), [Databases](), [Linux Kernel](), [NVMe]() Tags: [asynchronous](), [database-performance](), [io](), [io-uring](), [nvme](), [performance]() ### AI overview This article explains how io_uring improves database performance through shared submission and completion queues, batching, fewer system calls, zero-copy operation, and features such as SQPoll and registered buffers. It also discusses DMA and the relevance of fast NVMe storage. ### Source excerpt . [How io_uring Improves Database Performance](how-iouring-improves-database-performance-cover... ## Bloom filters: the niche trick behind a 16x faster API DevFeed: [Bloom filters: the niche trick behind a 16x faster API]() Original publisher: [Read original article]() Author: Mike Fisher Published: 2025-11-14T11:09:53Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [API](), [Latency](), [Computer science](), [Databases](), [Monitoring]() Tags: [api](), [deep-dive](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [io](), [latency](), [outage](), [performance](), [post-mortem](), [postgres](), [slack-incident]() ### AI overview This deep dive explains how incident.io reduced the P95 latency of an API endpoint from 5 seconds to 0.3 seconds using a Bloom filter. It describes the alert-history filtering problem, the performance impact of handling millions of alerts in Postgres, the alternatives considered, and the underlying technique. ### Source excerpt This post is a deep dive into how we improved the P95 latency of an API endpoint from 5s to 0.3s using a niche little computer science trick called a bloom filter. ## Introducing Turso in the Browser DevFeed: [Introducing Turso in the Browser]() Original publisher: [Read original article]() Author: Nikita Sivukhin Published: 2025-10-08T00:00:00Z Content type: article Language: en Sources: [Turso Blog]() Topics: [Turso](), [SQLite](), [WebAssembly](), [browser](), [web applications](), [Persistence](), [IO]() Tags: [browser](), [io](), [offline](), [performance](), [persistence](), [sqlite](), [turso](), [web-applications](), [webassembly]() ### AI overview The article introduces Turso in the Browser, a browser-based SQLite implementation delivered through WebAssembly. It describes asynchronous database APIs, local and ephemeral in-memory databases, OPFS-based filesystem persistence, Web Workers, SharedArrayBuffer communication, and bundler integration for web applications. ### Source excerpt Turso in the Browser ships SQLite as WebAssembly with OPFS persistence and SharedArrayBuffer performance, powering offline-first web apps with no server. ## Locality, and Temporal-Spatial Hypothesis DevFeed: [Locality, and Temporal-Spatial Hypothesis]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2025-10-05T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Databases](), [Caching](), [systems](), [IO](), [Streaming](), [Time Series](), [observability]() Tags: [cache](), [database](), [database-performance](), [io](), [linux](), [metrics](), [observability](), [performance](), [postgres](), [streaming](), [systems](), [time-series]() ### AI overview The article examines locality in database and computer-system performance, focusing on how temporal and spatial locality influence caching, read-ahead, and data layout. It develops the temporal-spatial locality hypothesis and compares its relevance for streaming, time-series, metrics, observability, and hash-based database systems. ### Source excerpt Locality, and Temporal-Spatial Hypothesis Good fences make good neighbors? Last week at PGConf NYC, I had the pleasure of hearing Andres Freund talking about the great work he's been doing to bring async IO to Postgres 18. One particular result caught my eye: a large difference in performance between forward and reverse scans, seemingly driven by read ahead1. The short version is that IO layers (like Linux's) optimize performance by proactively pre-fetching data ahead of the current read point in a file, so it's already cached when needed. Notably, most of these systems don't do this backwards. This leads to a big difference in performance between forward scans (where the pages are already in the cache when they're needed) and backward scans (where the database needs to block on IO to fetch the next page). This lead me to thinking more about a particular hypothesis behind many database designs: a temporal-spatial locality hypothesis2. Before we get there, let's talk about locality more generally, because it might be the single most important idea in database performance (and computer systems performance generally). Temporal locality is the idea that data accessed recently is likely to be accessed again soon. This idea is what's behind CPU caches, database buffer pools, and most caches you'll come across in computer systems. Spatial locality is the idea that when we access data, we're likely to access nearby data soon. Almost all database systems take advantage of these forms of locality, and would lost significant performance without taking advantage of them. Stacks of books could be written about these ideas. Stacks of books have been written about these ideas. We could talk about cache-oblivious algorithms, or non-polluting read and write instructions, or have an argument about linked lists. Instead, I want to zoom in to a particular idea in databases: temporal-spatial hypothesis. The hypothesis I mean has a definition something like this: Temporal-spatial localit ## IO Activity Tagging DevFeed: [IO Activity Tagging]() Original publisher: [Read original article]() Author: Hui Xiao Published: 2025-09-25T00:00:00Z Content type: article Language: en Sources: [RocksDB]() Topics: [rocksdb](), [IO](), [systems]() Tags: [blog](), [caching](), [enum-class](), [io](), [management](), [operations](), [performance](), [rocksdb](), [structure](), [systems](), [verification]() ### AI overview This article explains RocksDB's IOActivity enum, which automatically tags operations such as reads, flushes, compactions, database opens, and verification. The tags are propagated through the storage stack so custom file systems can make activity-aware scheduling, caching, and resource-management decisions. RocksDB also provides per-activity IO time and count histograms. ### Source excerpt Context RocksDB performs a variety of IO operations--user reads, background compactions, flushes, database opens, and verification tasks. Treating all these operations the same makes it difficult for file system implementers to optimize performance, prioritize latency-sensitive IOs, and diagnose bottlenecks. To solve that, RocksDB internally tags every IO operation with its activity type using the IOActivity enum. This automatic tagging provides precise context for each IO, enabling file systems to make smarter, context-aware decisions for scheduling, caching, and resource management. How Internal IO Tagging Works RocksDB automatically assigns an IOActivity tag to each IO operation. This tag is propagated through the storage stack and included in the IO options passed to the file system. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 enum class IOActivity : uint8_t { kFlush = 0, // IO for flush operations (background write) kCompaction = 1, // IO for compaction (background read/write) kDBOpen = 2, // IO during database open (read/write) kGet = 3, // User Get() read kMultiGet = 4, // User MultiGet() read kDBIterator = 5, // User iterator read kVerifyDBChecksum = 6, // Verification: DB checksum kVerifyFileChecksums = 7, // Verification: file checksums kGetEntity = 8, // Entity Get (e.g., wide-column) kMultiGetEntity = 9, // Entity MultiGet kGetFileChecksumsFromCurrentManifest = 10, // Manifest checksum reads // 0x80-0xFE: Reserved for custom/internal use kUnknown = 0xFF // Unknown/unspecified activity }; Access IO Tag in File System Custom file systems can access the IOActivity tag via the IO options structure provided by RocksDB. This allows them to optimize behavior based on the specific IO activity. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Status CustomFileSystem::Append(uint64_t offset, const Slice& data, const IOOptions& io_opts, ...) { switch (io_opts.io_activity) { case Env::IOActivity::kGet: // Prioritize or cache user reads break; case Env::IOActivity::kCompaction: // T [Next page]()