Memoエモさ駆動開発2019-04-23WSLのIO遅いよ問題WSLは理論的にはLinuxカーネルを起動するオーバーヘッドがなく軽量に動作するはずなのだが、実際に動かしてみると色々ともっさりしている。installなどが重たすぎて永遠に終わらなかったりエラーが出てしまったり。この辺のもっさりは、WSLのIOが重いことに起因する。www.phoronix.com↓のスレッドではWSLのIOはなぜ遅いのか問題が議論されている。github.comSvenGrootさんの説明1LinuxのIO操作とWindowsのIO操作の設計が根本的に違うことが原因。解決しようとしたら、Linuxの挙動を完璧に再現しなければならない。Defenderやサードパーティのウィルス対策ソフト)などの沢山の関係者がいて、複雑でとても進みの遅い作業になる。Updateではstatコールのパフォーマンスを向上させる新しいファイルシステムAPIを導入した。この変更を知らせ、使用してもらうために内外のベンダに働きかけている。ファイルシステムのパフォーマンス問題は難しい、けど改善を続けてくよ。苦しみはわかるけど問題を無視してるわけじゃないよ。ファイルのIOにサードパーティが独自の処理を挟めるもの。Defenderはこれを使ってファイル変更の監視をしているSvenGrootさんの説明2ここまでの問題は簡単に言えば、"NTFSは遅い"か"DrvFSは遅い"だと思う。IOサブシステムはWindowsとLinuxでかなり違う設計になっている。大きな違いは以下の3点。Linuxはトップ階層にキャッシュを持っていて、キャッシュに存在するエントリに関してはFS内部を探索しなくても返すことができる。Windowsにはこのようなキャッシュがなく、ファイルシステムに大きく頼っている。Win32の「C:\dir\file」のようなパスは「\??\C:\dir\file」というNTパスに変換され、「\??\C:」部分はObjectManagerが管理する\Device\HarddiskVolume4などへのデバイスオブジェクトへのシンボリックリンクを表している。一度このようなデバイスオブジェクトを発見すると、Windowsは残りのパスを単純にファイルシステムへ託す。ここがLinuxのVFSが行うような中央集権的なパス解析との違いである。WindowsのIOスタックは拡張性を重視しており、ファイルシステムへのIO操作要求を実行する前にフィルタドライバを設定することができるようになっている。これは、例えばウィルススキャン、圧縮、暗号化、OneDriveのような仮想的なファイル、アプリの起動高速化のためのpre-fetchingなどなど至る所で使われている。Windowsをクリーンインストールしたとしても、すでにWindowsはある程度の数のフィルターが特にシステムドライブ(C:)に関しては動いている。(なのでD:ドライブや他のパーティションが存在するマシンなら、よりフィルタが少ない傾向にあるシステムドライブ以外を使うことを推奨する)これらのフィルタは沢山のIO操作、特にファイルのオープンと作成に設定されている。NTのファイルシステムAPIはパスベースではなく、ハンドルベースで設計されている。ほとんどいかなる操作もはじめにファイルを開きハンドルを取得する必要があり、この操作はパフォーマンスに影響する。APIでファイル削除の1コール(DeleteFileなど)を実行したとしても、実際にはOpen/Close操作が走っている。前にリリースしたDrvFSの大きな改善は、ファイルの情報取得のためにファイルを開かなくても良い新しいAPIを用意することだった。基本的にファイル操作はLinuxよりもWindowsの方が重い。ファイルのメタ情報に触れる操作は。Manager*2、フィルタ、そしてNTFSに広がっている。単純に「NTFSが遅い」というだけならNTFSの最適化の修正を行えば良いが、問題は広大なコンポーネントに広がっており、銀の弾丸がない状況である。内製のフィルタだけならまだいいが、サードパーティのフィルタが内部で何を行なっているかは知るすべがないので、各ベンダと共にこれらの問題の改善を試している。ファイル情報を取得する新しいAPIを導入し、フィルタドライバもそのAPIをサポートした時、まだ新しいAPIに対応していないフィルタがインストールされていたとしても正常に動作することを保証しなければならなかった(基本的にはOpen/Query/Close処理へフォールバックする)。その他もこれをサポートしていることを確認し、最大のパフォーマンスの恩恵を受けられるようにするためには沢山の時間と労力がかかった。同じことが大文字小文字を区別するディレクトリなどにも言え、変更後の動作をフィルタのエコシステムが正常にハンドルできるのか確かめなければならない。...中略...また、単純に「Windowsが遅さの原因」と言うわけではなく、WSLの影響もある。WindowsとLinuxのパス解析の挙動の大きな違い(Linuxは中央集権、上でも述べた通りWindowsはファイルシステムに任せている)がある。LinuxアプリはLinuxの挙動を想定して作られている。我々も慎重にその挙動をエミュレートし、不幸なことにも沢山のIO操作をファイルシステムに送ることになってしまっている。statコールも、Linuxはキャッシュ*3にヒットさえすればLinuxカーネルが全体を応答するが、WSLではフィルタ全体を走査する複数のリクエストをファイルシステムに対して送らなければならない。我々はWSLで余計な処理が必要にならないよう沢山の作業を間も無くリリースされる1809で行なった。APIが違う以上、ここにはどうしても余計な処理が必要になってしまう。Partnersと共に取り組んでいかなければならない問題である。いって諦めるわけではないよ〜。外部入出力を管理するコンポーネント。02:40WSLのIO遅いよ問題Tweet広告を非表示にする関連記事2019-11-23チーム異動後のターミナル周り半年前にチームの移動をした。Windows)環境のために最近、Macを捨ててWindowsに乗り換えた。その際に、Macで使用し...2015-08-23お金がない人のためのオススメMacアプリ貧乏だけど奮発してMacを買ってみたみなさん。アプリストアは...2015-08-23cowsay日本語化cowsayというコマンドをご存知だろうか。<p>wait0000さんは、はてなブログを使っています。<p>引用をストックできませんでした。<p>限定公開記事のため引用できません。