# シムレイヤー ## 定義 シムレイヤーとは、アプリケーションとオペレーティングシステム(またはデバイス)の間に割り込んで(interposition)、両者を変更せずに機能を追加・変更する userspace のソフトウェア層である。[[@2025__SoCC__Valet - Efficient Data Placement on Modern SSDs]] は、[[ホスト誘導データ配置]] の責務をアプリケーションにもファイルシステム(カーネル)にも負わせず、この中間のシムレイヤーに切り出すべきだと論じる。理由は、アプリケーション書き換えは API 変化のたびに陳腐化し可搬性を損なうこと、ファイルシステム変更はカーネル内変更ゆえに保守コストとセキュリティリスクが高いことの両方を回避できるためである。(Source: [[@2025__SoCC__Valet - Efficient Data Placement on Modern SSDs]]) ## 横断的知見 - **シムレイヤーの実装技術には複数の選択肢があり、性能とカーネル境界コストのトレードオフがある**: 論文 Table 2 は eBPF・WASM・FUSE・LD_PRELOAD を比較し、LD_PRELOAD のみが「追加カーネル境界なし・静的リンク不要・カーネル変更不要」を満たし性能劣化が最小(著者ら計測で1システムコールあたり約2 µs、対して syscall_intercept は約2 ms)であるとする。一方 eBPF は約10倍、WASM は約2.5倍、FUSE は約1.8倍の性能劣化を伴うと引用されている。(Source: [[@2025__SoCC__Valet - Efficient Data Placement on Modern SSDs]]) - **LD_PRELOAD ベースのシムレイヤーは、ZNS のような host-managed インターフェースに対しては軽量な仮想ファイルシステム(独自のデータ管理エンジン)を伴う必要がある**: [[Valet]] の `valet-mapper` は、単純なヒント転送(multi-stream・FDP 向け)を超えて、extent 管理・buffering・garbage collection まで userspace 内で完結させる設計を取る。これは、シムレイヤーが単なる「呼び出しの書き換え」にとどまらず、デバイス管理責務そのものを userspace に引き受けうることを示す。(Source: [[@2025__SoCC__Valet - Efficient Data Placement on Modern SSDs]]) - **シムレイヤー方式はカーネル内コード追加を避けることで、追加コード行数と攻撃対象領域を大幅に削減できる**: 論文 Table 4 は zenfs(アプリケーション4017行+userspace 988行)、f2fs(zns)(カーネル38,188行+userspace 1252行)に対し、Valet はカーネル・アプリケーション変更ゼロで userspace 1700行のみとする。(Source: [[@2025__SoCC__Valet - Efficient Data Placement on Modern SSDs]]) ## 未解決の問い - LD_PRELOAD は静的リンクされたバイナリや libc を使わない言語(Golang・Java 等)には適用できない。これらの環境でシムレイヤー方式の利点(監査可能性・カーネル変更不要)を維持できる代替実装技術(カスタム libc・WASI など)の性能・保守コストはどの程度か。 - fork-exec を多用する複雑なクライアント・サーバアプリケーションで、preload が意図通り継承されない場合がある。この制約は、シムレイヤー方式全般にどこまで一般化する課題か。 - シムレイヤーがデバイス管理責務(garbage collection・extent management)まで引き受ける場合、ファイルシステムが本来提供する機能(アクセス制御・ロッキング・サードパーティツールとの互換性)との境界線をどこに引くべきか。 ## 関連 - ソース: [[@2025__SoCC__Valet - Efficient Data Placement on Modern SSDs]] - 概念: [[ホスト誘導データ配置]] - エンティティ: [[Valet]]