[論文レビュー] Understanding NVMe Zoned Namespace (ZNS) Flash SSD Storage Devices

Nick Tehrany, Animesh Trivedi|arXiv (Cornell University)|Jun 3, 2022

Advanced Data Storage Technologies被引用数 6

ひとこと要約

本論文は、NVMe Zoned Namespace (ZNS) SSDの体系的性能評価を提示し、Linuxにおけるブロックレベル統合を分析。大きなI/Oサイズ（≥16KiB）が必要であることが判明し、デバイス帯域幅を飽和させるために不可欠であり、I/Oスケジューラの設定がワークロードパターンに応じて性能に顕著な影響を与える。本研究は、実測値に基づくZNSストレージスタック統合の初期ガイドラインを提供し、ゾーン管理およびマルチワークロード干渉における主な課題を強調している。

ABSTRACT

The standardization of NVMe Zoned Namespaces (ZNS) in the NVMe 2.0 specification presents a unique new addition to storage devices. Unlike traditional SSDs, where the flash media management idiosyncrasies are hidden behind a flash translation layer (FTL) inside the device, ZNS devices push certain operations regarding data placement and garbage collection out from the device to the host. This allows the host to achieve more optimal data placement and predictable garbage collection overheads, along with lower device write amplification. Thus, additionally increasing flash media lifetime. As a result, ZNS devices are gaining significant attention in the research community. However, with the current software stack there are numerous ways of integrating ZNS devices into a host system. In this work, we begin to systematically analyze the integration options, report on the current software support for ZNS devices in the Linux Kernel, and provide an initial set of performance measurements. Our main findings show that larger I/O sizes are required to saturate the ZNS device bandwidth, and configuration of the I/O scheduler can provide workload dependent performance gains, requiring careful consideration of ZNS integration and configuration depending on the application workload and its access patterns. Our dataset and code are available at https: //github.com/nicktehrany/ZNS-Study.

研究の動機と目的

• ZNS SSDをホストストレージスタックに統合する際の性能的影響を体系的に評価すること、特にブロックデバイスレベルでの統合を対象とする。
• ZNSデバイス上で高い性能を達成するための最適な設定戦略（特にI/Oサイズとスケジューラ選択）を特定すること。
• ZNSストレージを標的とするシステム設計者およびアプリケーション開発者に実行可能な開発ガイドラインを提供すること。
• 共有ZNSデバイス上でのゾーン管理、ガーブリッジコレクション、およびマルチアプリケーション干渉の課題を調査すること。
• 将来のZNS研究および統合作業を避けるべき失敗した実験や落とし穴を文書化すること。

提案手法

• 標準化されたI/Oワークロードを用い、I/Oサイズを変化させながら、順方向およびランダム読み書きワークロードにおけるZNS SSDの性能をベンチマークする。
• 異なるI/Oスケジューラ（例：mq-deadline、kyber）が、多様なアクセスパターン下でのZNSデバイス性能に与える影響を評価する。
• Linuxカーネルのdm-zapデバイスマッパー・モジュールを介してブロックレベルでのZNS統合を実装・テストする。
• 高デバイス使用率（例：95％満杯）におけるガーブリッジコレクションの挙動と性能低下を分析する。
• 公開GitHubリポジトリを通じて包括的なデータセット、ベンチマークスクリプト、および設定手順を収集・公開する。
• 複数のアプリケーションが同じZNSデバイスまたはネームスペースを共有する状況での干渉を評価するための制御された実験を実施する。

実験結果

リサーチクエスチョン

• RQ1 順方向およびランダムワークロード下で、異なるI/OサイズとI/Oスケジューラ設定がZNS SSDの性能に与える影響は何か？
• RQ2 ガーブリッジコレクションの性能は、統合レベル（ブロック、ファイルシステム、アプリケーション）およびデバイス使用率に応じてどのように変化するか？
• RQ3 同じZNSデバイス上で複数のアプリケーションが同時に実行される場合、ガーブリッジコレクションおよびI/Oスケジューリングの観点から、お互いにどの程度干渉し合うか？
• RQ4 既存のLinuxストレージスタックにZNSデバイスを統合する際の主なパフォーマンスボトルネックと誤設定は何か？
• RQ5 デバイスがアクティブなゾーン数に制限を設けるが、割り当てポリシーを強制しない状況下で、複数のネームスペースおよびアプリケーション間でゾーン管理と公平なリソース共有をどのように確保できるか？

主な発見

• ZNSデバイスにおける順方向読み込みは、順方向書き込みと比較してほぼ2倍のピーク帯域幅を達成しており、性能に顕著な非対称性が存在することが示された。
• デバイスの帯域幅を飽和させるには、16KiB以上のI/Oサイズが必要であることが判明し、小規模なI/Oは高スルーレートワークロードには非効率であることが示唆された。
• I/Oスケジューラの選択（例：mq-deadline対kyber）は、ワークロードに応じたパフォーマンス向上をもたらすが、万能な最適なスケジューラは存在しない。
• 95％のデバイス使用率では、ガーブリッジコレクションのオーバーヘッドが顕著に顕在化し、特にランダム書き込みワークロード下で顕著になる。これは、ワークロードに応じた注意深いチューニングの重要性を示唆している。
• ZNSデバイスには、複数のネームスペースやアプリケーション間でアクティブゾーンの制限を管理するための強制メカニズムが現在存在せず、公平なリソース共有のためには外部でのゾーン管理が不可欠である。
• 本研究では、既存のソフトウェアスタックがゾーンに配慮したガーブリッジコレクションポリシーをネイティブにサポートしていないことが判明し、ファイルシステムレベルでの最適化（例：作成時刻や廃棄時刻ごとにファイルをグループ化する）がパフォーマンスを顕著に向上させ得ると示唆された。