Even a fast SSD cannot deliver its full performance if the operating system's internal processing can't keep up. On November 11, 2026, KAIST announced that a research team led by Professor Youjip Won had identified a data-processing bottleneck in the next-generation flash storage standard ZNS (Zoned Namespaces) and developed a new filesystem technology called GAZE (announcement). With conventional filesystems, reclaiming used space caused significant delays. The main cause was not the write speed of the flash memory but the CPU workload of data management and memory allocation.
The team reworked the internals of the Linux filesystem F2FS, parallelizing the processing required for space reclamation and making memory management more efficient. As a result, the time to reclaim 1GB of space fell from 1.70 seconds to 0.58 seconds, and in certain benchmarks throughput rose by up to 3x. The approach requires neither additional dedicated hardware nor changes to the storage write format. The research was presented on September 30, 2026, at ACM SOSP 2026, an international operating systems conference held in Prague, Czech Republic, and published on pages 321–336 of the proceedings as "GAZE: Rearchitecting Log-Structured Filesystem for Garbage Collection on Zoned Namespace Flash Storage".
Gigabyte-scale reclamation burdens the CPU
In conventional SSDs, an internal controller manages the mapping between logical and physical addresses and controls data placement and the reuse of space. Flash memory cannot overwrite existing data in place; blocks must be erased in fixed units before new data is written. If a block to be erased still holds valid data, that data must first be moved elsewhere, after which the original block is erased. This process is called garbage collection (GC).
In conventional SSDs, garbage collection is mainly run by firmware inside the controller. As a result, the OS has little visibility into what is happening internally, and data movement and erasure can cause unexpected write delays. ZNS emerged to mitigate such problems. ZNS divides the storage address space into "zones" ranging from several MB to several GB, and generally restricts writes to each zone to sequential appends. This is expected to reduce the burden of address translation and background processing inside the SSD, and to improve write endurance and performance predictability.
However, with ZNS, the host-side OS and filesystem must take on part of the space management that used to be done inside the SSD. On a typical block-based SSD, the filesystem writes data in units such as 4KB, and the SSD handles internal placement and space reclamation. With ZNS, the filesystem must manage sequential writes to zones, move valid data within a zone, and return the entire zone to a reusable state. When a zone's capacity exceeds 1GB, a single reclamation can involve moving hundreds of MB to several GB of data.
Existing log-structured filesystems (LFS) were designed on the assumption that they would reclaim relatively small segments of a few tens of MB. zF2FS, the ZNS-compatible version of F2FS (Flash-Friendly File System), a representative implementation, also incurs a heavy reclamation burden when handling huge zones. The research team measured it with the storage benchmark tool FIO under a condition where 40% of the data in a zone was valid, and zF2FS took about 1.70 seconds to reclaim a 1GB zone. A breakdown of the processing showed that more than 70% of the load associated with reads and writes was spent not on physical access to storage but on software processing such as CPU-driven data state management and memory management.
The problem is that conventional filesystems assumed the reclamation of relatively small regions. In addition to a mechanism that processes huge zones sequentially, memory allocation and management that rely on the page cache, and exclusive control that halts application writes during reclamation, amplified the delays. Speeding up the flash memory itself does not improve performance if CPU-side processing can't keep up. GAZE was designed to eliminate this software-side bottleneck.
Three improvements: pipelining, a dedicated memory pool, and write control
GAZE leaves the SSD hardware untouched and reduces the waiting time involved in space reclamation by redesigning filesystem processing inside the Linux kernel. Building on F2FS, the team implemented three mechanisms: pipelined garbage collection, a dedicated page pool, and selective blocking. Each addresses a different bottleneck, and in combination they are designed to suppress stalls across overall write processing.
1. Pipelining garbage collection
In conventional reclamation, a single thread sequentially performed locating valid data, reading it from storage, processing it in memory, and writing it to another region. With this approach, the next step cannot begin until the previous one completes, so CPU processing and I/O waits alternate. With ZNS, which moves large amounts of data, this sequential processing was a cause of longer reclamation times.
GAZE splits reclamation into four stages — preread, read, prewrite, and write — and runs each in an independent kernel thread. The stages are connected by capacity-limited buffers, so while one stage prepares the next data, subsequent stages are already processing data they have received. This overlaps CPU processing with storage I/O and reduces waiting time. Rather than increasing threads without limit, the design regulates each stage's throughput via buffers, which also avoids resource contention from excessive parallelism.
2. A dedicated page pool for garbage collection
The second improvement is the "Garbage Collection Page Pool," which preallocates the memory used for reclamation. In conventional filesystems, each time valid data was evacuated, memory pages had to be allocated with the Linux kernel's general-purpose memory allocator and registered in the page cache's management structures. With ZNS, which moves data in gigabyte units, such allocation, registration, and release are repeated in large numbers, placing a heavy load on the CPU.
GAZE reserves a dedicated memory page pool when the filesystem is mounted and reuses it for garbage collection. It no longer needs to repeatedly call the general-purpose allocator, and it tracks data with a simple array instead of the complex page cache management structures. This reduces the time spent on memory allocation and page management.
3. Selective blocking: accepting writes during reclamation
The third mechanism, "Selective Blocking," minimizes write stalls during reclamation. To avoid running out of free blocks during garbage collection, the conventional zF2FS halted the application's write() system calls. However, ordinary file writes do not necessarily have to be reflected to the SSD immediately; they can be held in memory and written later.
GAZE uses delayed allocation to accept write requests that meet certain conditions into memory even during reclamation. In doing so, it considers not only the physical blocks currently available but also the invalid blocks expected to be reclaimed by the garbage collection in progress, and reserves the space that future writes will need. This lowers the risk of an ENOSPC error, which signals insufficient free space, when data accepted in memory is later written back to the SSD. However, write data cannot be accumulated in memory without limit; in the experiments, the dirty page limit was set to 20% of physical memory.
These three improvements deliver their full effect only in combination. Even if pipelining and the dedicated page pool speed up reclamation, waiting time remains if application writes stay halted. Conversely, with selective blocking alone, slow reclamation means dirty pages reach their limit and writes eventually stall. By speeding up reclamation itself while also accepting writes during it, GAZE improves the processing efficiency of the storage as a whole.
Testing on a 40-core server and a ZNS emulator
The team implemented GAZE on F2FS in Linux kernel 6.1.0 and compared its performance with existing filesystems. The main evaluation environment was a 40-core server with two Intel Xeon Gold 6230 CPUs, each with 20 cores and 40 threads, and 512GB of DRAM. In the experiments, 64GB of memory was allocated, and filesystem behavior was measured using a 256GB SSD emulator based on FEMU.
The ZNS emulator was configured with a 1GB zone size, 8 channels, 4 chips per channel, 96KB flash pages, 32MB flash blocks, and a 4MB write-back cache. The paper states that the error rate against a real SSD is within 3.3%, but this figure alone does not guarantee that the emulator reproduces the behavior of every real-world environment. Caution is especially warranted for behaviors specific to actual flash storage, such as wear leveling and thermal throttling (performance limits caused by rising temperature). The research also included separate real-device validation using mobile storage products, but this must be considered separately from the evaluation on the server-oriented ZNS emulator.
For comparison, the team used zF2FS, an existing ZNS-compatible filesystem, along with the earlier research systems ZNS+ and P-GC. It also included ScaleLFS and IPLFS, log-structured filesystems for conventional block-based SSDs. Because these two do not support ZNS's zone management interface, they were evaluated in a separate environment emulating an SN640-class block-based SSD.
The main benchmark used FIO, running a heavy-load test of repeated 4KB random writes to a 180GB file with one thread. This condition produces a large number of invalid blocks and frequent garbage collection, making differences in reclamation performance easy to examine. The team also compared performance on workloads modeled on file servers and databases, including Fileserver, YCSB-A, YCSB-F, and TPC-C. All of these are write-heavy tests with frequent data updates, and differ in nature from environments such as AI inference, where reads dominate.
Reclaim time falls from 1.70 to 0.58 seconds; write performance up to 3x
In the experiments, GAZE improved both the time required for garbage collection and write throughput. In the FIO test with 40% valid data in the target zone, the conventional zF2FS took 1.70 seconds to reclaim a 1GB zone, whereas GAZE cut this to 0.58 seconds. That is a reduction of about 66%, or roughly one-third of the previous time.
データを表で見る
| 回収時間 (秒) | |
|---|---|
| zF2FS（従来方式） | 1.7 |
| GAZE | 0.58 |
The team also ran ablation experiments to examine the effect of each mechanism individually. According to the paper, pipelining garbage collection alone cut the reclamation time of a 1GB zone by 51%. Introducing the dedicated page pool reduced read-phase latency by 32%. Because the publicly available materials we could check do not give absolute times before and after these comparisons, the improvement from each mechanism cannot simply be added together.
The effect of the dedicated page pool is also confirmed by measurements of time spent on memory management. Free-page allocation time fell from 210 milliseconds to 50 milliseconds, a reduction of about 76%. The processing time equivalent to insertion into the page cache's management structures also dropped from 73 milliseconds to 5 milliseconds, cutting about 94% of the overhead. These improvements bear out that CPU-side management was a major burden in conventional reclamation.
With all three mechanisms enabled, overall FIO throughput improved by 95% over the zF2FS baseline. When pipelining or the dedicated page pool was applied individually, faster reclamation did not translate directly into better application write performance. Only when combined with selective blocking, which reduces write stalls during reclamation, did it lead to improved throughput for the filesystem as a whole.
In FIO comparisons with other ZNS-compatible filesystems, GAZE recorded up to 3x the throughput of zF2FS, P-GC, and ZNS+. In comparisons with filesystems for conventional block-based SSDs, performance differences of up to 4.4x over ScaleLFS and up to 1.32x over IPLFS were reported. However, the latter comparisons used a different storage interface and are not results from swapping only the filesystem under identical conditions. Moreover, ScaleLFS could not run the macro benchmarks to completion because of metadata inconsistency errors, so no comparison results were obtained for those tests.
Improvements were also confirmed in macro benchmarks modeled on real applications. Gains of up to 1.9x over zF2FS were reported for Fileserver, and up to 1.8x over P-GC and ZNS+ for YCSB-A. However, these multiples were all obtained under specific conditions and do not mean the same improvement is achieved for every workload. In addition, the publicly available materials we could check do not give absolute throughput values (such as MB/s or IOPS) for each condition, making it difficult to directly judge what processing capacity this would correspond to in real operation.
The main measurement results and comparison conditions are summarized below.
| Filesystem / configuration | Main changes | Reported result | Comparison conditions and caveats |
|---|---|---|---|
| zF2FS (conventional) | Sequential reclamation and general-purpose page cache management | 1.70 seconds to reclaim a 1GB zone | FIO, 4KB random writes. 40% valid data. Over 70% of processing load attributable to the CPU side |
| GAZE (pipelining only) | Reclamation split into four stages and run in parallel | Reclaim time cut by 51% | Absolute before/after times not given in the publicly available materials we could check. Write-stall problem remains |
| GAZE (dedicated page pool) | Preallocated dedicated memory and array-based data management | Allocation time down 76%, insertion time down 94%, read latency down 32% | Allocation 210→50 ms, insertion 73→5 ms |
| GAZE (all mechanisms integrated) | Pipelining, dedicated page pool, selective blocking | Reclaim time 0.58 seconds, FIO throughput up 95% | Comparison in a ZNS environment. The up-to-3x gain over prior methods was obtained under a different comparison condition |
| ScaleLFS | Parallel LFS for conventional block SSDs | GAZE up to 4.4x in FIO | Evaluated on an SN640-class block SSD emulator. Macro tests not completed |
| IPLFS | Page-granularity LFS for conventional block SSDs | GAZE up to 1.32x in FIO | Evaluated on a block SSD emulator, not ZNS |
These results are performance measurements obtained on a specific hardware configuration and workloads. The materials we could check do not present confidence intervals or hypothesis test results for the reported reductions and performance multiples. The figures should therefore be evaluated as implementation-level improvements under the experimental conditions. Whether the same multiples would be obtained on different SSDs, CPUs, or write patterns requires separate verification.
Faster AI inference is a future question; real-SSD validation is also needed
The key achievement of GAZE is that it delivered a large performance improvement through filesystem changes alone, without altering SSD hardware or the data write format. With concrete measurements, it showed that even in processing traditionally thought to be limited by storage speed, the OS's state management and memory management can be the bottleneck. The team says the design approach could be applied to log-structured filesystems other than F2FS. However, the main implementation and performance evaluation here were based on F2FS, and the effect of porting it to other filesystems has not been demonstrated.
KAIST's announcement also presents GAZE as a technology that could lead to faster AI inference and data centers. However, what this study directly confirmed was improved filesystem reclamation and write performance. In typical large language model (LLM) inference, model weights are read from storage, but computation during inference and access to the KV cache take place mainly in GPU memory and similar. Accordingly, speeding up garbage collection on ZNS storage does not necessarily improve LLM generation speed by itself.
The paper does not measure metrics directly relevant to AI inference, such as generation speed in tokens/s, model load time, inference response latency, overall system power consumption, or model-serving throughput. The benchmarks here also centered on random writes with FIO and database-style workloads with frequent data updates. Storage requirements differ between such conditions and read-dominated AI inference environments. Faster AI inference should therefore be seen as a potential future application, not a result confirmed in these experiments.
Reproducibility on real SSDs is also an important open question. The main evaluation used a FEMU-based emulator, but on actual enterprise SSDs, wear leveling, thermal control, vendor-specific firmware, and other factors affect performance. In production environments where multiple applications read and write simultaneously, contention for CPU, memory, and storage I/O also arises. Whether GAZE's pipelining and dedicated page pool remain effective under such conditions must be confirmed through additional evaluation on real devices.
GAZE improved on a conventional filesystem that needed 1.70 seconds to reclaim a 1GB zone, cutting that time to 0.58 seconds. This shows that the reclamation bottleneck in ZNS storage depends heavily on software design as well as hardware. However, not all processing delays have been eliminated, and it is not yet clear whether equivalent improvements can be obtained in real operating environments.
The next questions are whether GAZE's design will evolve into a practical Linux kernel implementation, and whether the performance gains can be reproduced in data center environments using real SSDs. In particular, measuring latency under workloads mixing writes and reads, and the effect on overall AI inference system processing time, will be important for judging the technology's practicality.