高速なSSDを搭載していても、OS内部の処理が追いつかなければ、その性能を十分に引き出すことはできない。韓国科学技術院(KAIST)は2026年11月11日、Youjip Won教授らの研究チームが、次世代フラッシュストレージ規格「ZNS(Zoned Namespaces)」におけるデータ処理のボトルネックを特定し、新たなファイルシステム技術「GAZE」を開発したと発表した。従来のファイルシステムでは、使用済み領域を再利用する際に大きな遅延が発生していたが、その主な原因はフラッシュメモリの書込み速度ではなく、CPUが担うデータ管理やメモリ割当ての負荷にあった。
研究チームはLinuxのファイルシステム「F2FS」の内部構造を見直し、領域回収に必要な処理の並列化とメモリ管理の効率化を図った。その結果、1GBの領域を回収する時間を従来の1.70秒から0.58秒に短縮し、特定のベンチマークでは最大3倍のスループットを記録した。専用ハードウェアの追加やストレージの書込み形式の変更を必要としない点も特徴だ。研究成果は、2026年9月30日にチェコ・プラハで開催されたオペレーティングシステム分野の国際学会「ACM SOSP 2026」で発表され、論文『GAZE: Rearchitecting Log-Structured Filesystem for Garbage Collection on Zoned Namespace Flash Storage』として論文集の321〜336ページに掲載された。
ギガバイト単位の領域回収がCPUの負担に
従来の一般的なSSDでは、内部のコントローラーが論理アドレスと物理アドレスの対応関係を管理し、データの配置や領域の再利用を制御している。フラッシュメモリは既存データをそのまま上書きできず、新しいデータを記録する前に、一定のブロック単位で消去しなければならない。消去対象のブロックに有効なデータが残っている場合は、それを別の場所へ移動したうえで元のブロックを消去する。この処理が「ガーベジコレクション(GC)」である。
従来型SSDでは、ガーベジコレクションを主にコントローラー内部のファームウェアが実行する。そのため、OSからは内部の処理状況が見えにくく、データの移動や消去が予期せぬ書込み遅延を引き起こすことがある。こうした問題を軽減するために登場したのがZNSだ。ZNSでは、ストレージのアドレス空間を数MBから数GB規模の「ゾーン」に分割し、各ゾーンへの書込みを原則として順次追記に制限する。これにより、SSD内部のアドレス変換やバックグラウンド処理の負担を軽減し、書込み耐久性や性能の予測可能性を改善することが期待されている。
ただし、ZNSでは従来SSD内部で行われていた領域管理の一部を、ホスト側のOSやファイルシステムが引き受ける必要がある。一般的なブロック型SSDでは、ファイルシステムが4KB単位などでデータを書き込み、SSD側が内部の配置や領域回収を処理していた。一方、ZNSではファイルシステムがゾーンへの順次書込みを管理するとともに、ゾーン内の有効データを移動し、領域全体を再利用可能な状態に戻さなければならない。ゾーンの容量が1GBを超える場合、1回の回収で数百MBから数GBものデータを移動することになる。
既存のログ構造化ファイルシステム(Log-structured Filesystem:LFS)は、数十MB程度の比較的小さなセグメントを回収することを前提に設計されてきた。代表的な実装であるF2FS(Flash-Friendly File System)のZNS対応版「zF2FS」も、巨大なゾーンを扱う際には領域回収の負担が大きくなる。研究チームがストレージベンチマークツールFIOを使い、ゾーン内の有効データ率が40%の条件で測定したところ、zF2FSでは1GBのゾーンを回収するのに約1.70秒を要した。さらに処理の内訳を分析すると、読出しや書込みに伴う負荷の70%以上が、ストレージへの物理的なアクセスではなく、CPUによるデータの状態管理やメモリ管理などのソフトウェア処理に費やされていた。
問題は、従来のファイルシステムが比較的小さな領域の回収を想定していたことにある。巨大なゾーンを逐次処理する仕組みに加え、ページキャッシュに依存したメモリの確保と管理、領域回収中にアプリケーションからの書込みを停止させる排他制御が、遅延を拡大させていた。フラッシュメモリ自体を高速化しても、CPU側の処理が追いつかなければ性能は改善しない。GAZEは、このソフトウェア側のボトルネックを解消するために設計された。
パイプライン化、専用メモリ、書込み制御の3つを改良
GAZEはSSDのハードウェアに手を加えず、Linuxカーネル内のファイルシステム処理を再設計することで、領域回収に伴う待ち時間を削減する。研究チームはF2FSをベースに、パイプライン化されたガーベジコレクション、専用ページプール、選択的ブロックという3つの仕組みを実装した。それぞれが異なるボトルネックを解消する役割を担い、組み合わせることで書込み処理全体の停滞を抑える設計となっている。
1. ガーベジコレクションのパイプライン化
従来の領域回収では、有効データの位置確認、ストレージからの読出し、メモリ上での処理、別の領域への書込みを、一つのスレッドが順番に実行していた。この方式では、前の工程が完了するまで次の工程に進めず、CPU処理とI/O待ちが交互に発生する。特に大量のデータを移動するZNSでは、この逐次処理が回収時間を長引かせる原因となっていた。
GAZEは回収処理を「事前読出し(preread)」「読出し(read)」「事前書込み(prewrite)」「書込み(write)」の4段階に分割し、それぞれを独立したカーネルスレッドで実行する。各工程は容量に上限を設けたバッファで接続され、前の工程が次のデータを準備している間に、後続の工程がすでに受け取ったデータを処理する。これにより、CPU処理とストレージI/Oを重ね合わせ、待ち時間を減らせる。無制限にスレッドを増やすのではなく、バッファを介して各工程の処理量を調整するため、過剰な並列化によるリソース競合も抑えられる。
2. ガーベジコレクション専用のページプール
2つ目の改良は、領域回収に使うメモリをあらかじめ確保する「Garbage Collection Page Pool」だ。従来のファイルシステムでは、有効データを退避させるたびにLinuxカーネルの汎用メモリアロケータを使ってメモリページを確保し、ページキャッシュの管理構造に登録する必要があった。ギガバイト単位のデータを移動するZNSでは、こうしたメモリの確保、登録、解放が大量に繰り返され、CPUに大きな負荷をかける。
GAZEではファイルシステムのマウント時に専用のメモリページプールを確保し、ガーベジコレクションで再利用する。汎用アロケータを繰り返し呼び出す必要がなくなり、データの追跡にも複雑なページキャッシュ管理構造ではなく、単純な配列を使用する。これにより、メモリ割当てとページ管理に費やされる時間を削減した。
3. 領域回収中も書込みを受け付ける選択的ブロック
3つ目の仕組みが、領域回収中の書込み停止を最小限に抑える「Selective Blocking」だ。従来のzF2FSでは、ガーベジコレクション中に空きブロックが不足する事態を避けるため、アプリケーションからのwrite()システムコールを停止させていた。しかし、通常のファイル書込みは必ずしも直ちにSSDへ反映する必要はなく、いったんメモリ上に保持して後から書き込むこともできる。
GAZEは遅延割当て(delayed allocation)の仕組みを利用し、領域回収中でも条件を満たす書込み要求をメモリ上に受け入れる。この際、現在利用可能な物理ブロックだけでなく、進行中のガーベジコレクションによって回収される見込みの無効ブロックも考慮し、将来の書込みに必要な領域を予約する。これにより、メモリ上で受け付けたデータを後からSSDへ書き戻す際に、空き容量不足を示すENOSPCエラーが発生するリスクを抑えている。ただし、書込みデータを無制限にメモリへ蓄積できるわけではなく、実験ではダーティページの上限を物理メモリの20%に設定している。
これら3つの改良は、組み合わせて初めて十分な効果を発揮する。パイプライン化と専用ページプールで領域回収を高速化しても、アプリケーションからの書込みを停止したままでは待ち時間が残る。一方、選択的ブロックだけを導入しても、領域回収が遅ければダーティページが上限に達し、いずれ書込みは停止する。GAZEは回収処理そのものを高速化するとともに、回収中も書込みを受け付けることで、ストレージ全体の処理効率を改善している。
40コアのサーバーとZNSエミュレータで性能を検証
研究チームはLinuxカーネル6.1.0上のF2FSをベースにGAZEを実装し、既存のファイルシステムと性能を比較した。主要な評価環境には、Intel Xeon Gold 6230を2基搭載した計40コアのサーバーを使用している。CPUは各20コア・40スレッドで、サーバーには512GBのDRAMが搭載されていた。実験では64GBのメモリを割り当て、FEMUをベースとする256GBのSSDエミュレータを用いてファイルシステムの動作を測定した。
ZNSエミュレータは、ゾーンサイズ1GB、8チャネル、各チャネル4チップ、フラッシュページ96KB、フラッシュブロック32MB、ライトバックキャッシュ4MBという構成だ。論文では実機SSDとの誤差率を3.3%以内としているが、この数値だけで、あらゆる実機環境の挙動を再現できるとは限らない。特に、ウェアレベリング(書込み平準化)やサーマルスロットリング(温度上昇による性能制限)など、実際のフラッシュストレージ特有の動作については注意が必要となる。研究ではモバイル向けストレージ製品を使った実機検証も別途行われているが、サーバー向けZNSエミュレータによる評価とは区別して考える必要がある。
比較対象には、ZNS対応の既存ファイルシステムであるzF2FSと、先行研究のZNS+、P-GCを採用した。また、従来のブロック型SSD向けログ構造化ファイルシステムであるScaleLFSとIPLFSも比較に含めている。ただし、これら2つはZNSのゾーン管理インターフェースに対応していないため、SN640相当のブロック型SSDをエミュレートした別の環境で評価した。
主要なベンチマークにはFIOを使用し、1スレッドで180GBのファイルに対して4KBのランダム書込みを繰り返す高負荷テストを実施した。この条件では大量の無効ブロックが生じ、ガーベジコレクションが頻繁に発生するため、領域回収の性能差を調べやすい。さらに、Fileserver、YCSB-A、YCSB-F、TPC-Cなど、ファイルサーバーやデータベースを想定したワークロードでも性能を比較した。いずれもデータの更新を頻繁に伴う書込み負荷の高いテストであり、AI推論のように読出しが中心となる環境とは性質が異なる。
回収時間は1.70秒から0.58秒に、書込み性能は最大3倍
実験の結果、GAZEはガーベジコレクションに要する時間と書込みスループットの双方で改善を記録した。対象ゾーンの有効データ率が40%のFIOテストでは、従来のzF2FSが1GBゾーンの回収に1.70秒を要したのに対し、GAZEでは0.58秒まで短縮された。回収時間の削減率は約66%で、従来の約3分の1に相当する。
データを表で見る
| 回収時間 (秒) | |
|---|---|
| zF2FS(従来方式) | 1.7 |
| GAZE | 0.58 |
研究チームは、各機構の効果を個別に調べるアブレーション実験も実施した。論文によると、ガーベジコレクションのパイプライン化だけで、1GBゾーンの回収時間は51%短縮された。また、専用ページプールを導入すると、読出しフェーズの遅延が32%減少したという。これらの割合については、確認できた公表資料に比較前後の絶対時間が示されていないため、各機構の改善幅を単純に足し合わせることはできない。
専用ページプールの効果は、メモリ管理に要する時間の測定からも確認できる。空きページの割当て時間は210ミリ秒から50ミリ秒に短縮され、約76%の削減となった。また、ページキャッシュの管理構造への挿入に相当する処理時間も、73ミリ秒から5ミリ秒へ減少し、約94%のオーバーヘッドを削減した。こうした改善は、従来の領域回収でCPU側の管理処理が大きな負担になっていたことを裏付けている。
3つの機構をすべて有効にした場合、FIOの総合スループットはzF2FSのベースラインと比較して95%向上した。パイプライン化や専用ページプールを個別に適用した場合には、領域回収の高速化がそのままアプリケーションの書込み性能に反映されるわけではない。回収中の書込み停止を減らす選択的ブロックを組み合わせることで、初めてファイルシステム全体のスループット改善につながった。
他のZNS対応ファイルシステムとのFIO比較では、GAZEはzF2FS、P-GC、ZNS+に対して最大3倍のスループットを記録した。また、従来のブロック型SSD向けファイルシステムとの比較では、ScaleLFSに対して最大4.4倍、IPLFSに対して最大1.32倍の性能差が報告されている。ただし、後者は異なるストレージインターフェースを使用した比較であり、同じ条件でファイルシステムだけを入れ替えた結果ではない。さらに、ScaleLFSはメタデータの不整合エラーによってマクロベンチマークを最後まで実行できず、同テストでの比較結果は得られていない。
実際のアプリケーションを模したマクロベンチマークでも改善が確認された。FileserverではzF2FSと比較して最大1.9倍、YCSB-AではP-GCおよびZNS+と比較して最大1.8倍の性能向上が報告されている。ただし、これらの倍率はいずれも特定条件で得られた結果であり、すべての負荷で同じ性能改善が得られることを意味しない。また、確認できた公表資料には各条件のスループットの絶対値(MB/sやIOPSなど)が示されていないため、実運用でどの程度の処理能力に相当するかを直接判断することは難しい。
主要な測定結果と比較条件を整理すると、次のようになる。
| ファイルシステム・構成 | 主な変更点 | 報告された結果 | 比較条件・留意点 |
|---|---|---|---|
| zF2FS(従来方式) | 逐次的な領域回収と汎用ページキャッシュ管理 | 1GBゾーンの回収に1.70秒 | FIO、4KBランダム書込み。有効データ率40%。処理負荷の70%以上がCPU側に起因 |
| GAZE(パイプライン化のみ) | 回収処理を4段階に分割して並列実行 | 回収時間51%短縮 | 比較前後の絶対時間は確認できた公表資料に記載なし。書込み停止の問題は残る |
| GAZE(専用ページプール) | 専用メモリの事前確保と配列によるデータ管理 | 割当て時間76%減、挿入時間94%減、読出し遅延32%減 | 割当て時間210→50ミリ秒、挿入時間73→5ミリ秒 |
| GAZE(全機構を統合) | パイプライン化、専用ページプール、選択的ブロック | 回収時間0.58秒、FIOスループット95%向上 | ZNS環境での比較。先行方式に対する最大3倍は別の比較条件で得られた値 |
| ScaleLFS | 従来型ブロックSSD向けの並列LFS | GAZEがFIOで最大4.4倍 | SN640相当のブロック型SSDエミュレータで評価。マクロテストは未完走 |
| IPLFS | 従来型ブロックSSD向けのページ単位LFS | GAZEがFIOで最大1.32倍 | ZNSではなくブロック型SSDエミュレータで評価 |
これらの結果は、特定のハードウェア構成とワークロードで得られた性能測定値だ。報告された短縮率や性能倍率について、確認できた資料には統計的な信頼区間や仮説検定の結果は示されていない。そのため、数値は実験条件における実装上の改善幅として評価する必要がある。異なるSSDやCPU、書込みパターンでも同じ倍率が得られるかは、別途検証が必要となる。
AI推論の高速化は今後の課題、実機SSDでの検証も必要
GAZEの重要な成果は、SSDのハードウェアやデータの書込み形式を変更せず、ファイルシステムの改良だけで大幅な性能改善を達成したことにある。従来はストレージ自体の速度が問題と考えられがちな処理でも、OS側の状態管理やメモリ管理がボトルネックになる場合があることを、具体的な測定結果で明らかにした。研究チームは今回の設計手法を、F2FS以外のログ構造化ファイルシステムにも応用できる可能性があるとしている。ただし、今回の主要な実装と性能評価はF2FSをベースとしたもので、ほかのファイルシステムに移植した場合の効果までは実証されていない。
一方、KAISTの発表では、AI推論やデータセンターの高速化につながる技術としてもGAZEが紹介されている。しかし、今回の研究で直接確認されたのは、ファイルシステムの領域回収と書込み処理の性能改善だ。一般的な大規模言語モデル(LLM)の推論では、モデルの重みをストレージから読み込む処理が発生するものの、推論中の計算やKVキャッシュへのアクセスは主にGPUメモリなどで行われる。したがって、ZNSストレージのガーベジコレクションを高速化しても、それだけでLLMの生成速度が改善するとは限らない。
論文では、生成速度を示すtokens/s、モデルのロード時間、推論応答のレイテンシ、システム全体の消費電力、モデルサービングのスループットなど、AI推論に直接関係する指標は測定されていない。今回のベンチマークも、FIOによるランダム書込みや、データ更新を頻繁に伴うデータベース系ワークロードが中心だった。こうした条件と、読出し主体のAI推論環境では、ストレージに求められる性能が異なる。そのため、AI推論の高速化は今回の実験で確認された成果ではなく、今後の応用可能性として捉える必要がある。
実機SSDでの再現性も重要な検証課題となる。今回の主要な評価ではFEMUベースのエミュレータが使用されたが、実際のエンタープライズSSDでは、ウェアレベリング、温度制御、メーカー独自のファームウェアなどが性能に影響する。また、複数のアプリケーションが同時に読み書きを行う本番環境では、CPU、メモリ、ストレージI/Oの競合も発生する。こうした条件でもGAZEのパイプライン化や専用ページプールが効果を発揮するかは、実機を用いた追加評価によって確かめる必要がある。
GAZEは、1GBゾーンの回収に1.70秒を要していた従来のファイルシステムを改良し、その時間を0.58秒まで短縮した。これはZNSストレージにおける領域回収のボトルネックが、ハードウェアだけでなくソフトウェア設計にも大きく左右されることを示す成果だ。ただし、すべての処理遅延が解消されたわけではなく、実際の運用環境で同等の改善が得られるかも明らかになっていない。
今後の焦点は、GAZEの設計がLinuxカーネルの実用的な実装へ発展するか、そして実機SSDを使用したデータセンター環境で性能改善を再現できるかにある。特に、書込みと読出しが混在するワークロードでの遅延や、AI推論システム全体の処理時間への影響を測定することが、技術の実用性を判断するうえで重要となる。



