WSLのファイルシステム解説。
LinuxはPOSIX互換システムなのでinodeベースのファイルシステムが使われていて、VFSで実際のファイルシステムとアプリケーションAPIから見えるファイルシステムと分離する仕組みになっており、Windowsのファイルシステムとは全然違うわけです。
このため、普通にやればWSL用にベアメタル上にパーティションを作ってそこにExt3なりLinuxのファイルシステムのドライブを構築するのが一番無難なわけですが、その作業自体煩わしいですしWSLではそんな普通な事はしていないわけです。
逆に見ればVFSの仕組みを使って、アプリケーションに対してNTFSを上手くinodeベースのファイルシステムに見せかける事が出来れば、アプリケーション側でファイルシステムの違いに対応する必要がなくなります。
このため、ほぼ完全にinodeベースのLinuxファイルシステムをエミュレートするVolFsとNTFSファイルシステムのディレクトリ、ファイルをinodeベースのファイルシステムに見せかけるDrvFSが作られました。
以下内容を要約してみます。
VolFs
WSLが使用するプライマリファイルシステムがにvolfsです。 Linuxのシステムファイル、ならびにLinuxのホームディレクトリの内容を格納するために使用されます。このように、volfsはLinuxのVFSをほとんどサポートし、Linuxのパーミッション、シンボリックリンク、FIFOは、ソケット、およびデバイスファイルを含め、提供しています。
volfsは、バッキングストレージとして%LocalAppData%\lxss\rootfsを使用して、VFSルートディレクトリをマウントするために使用されます。またそれ以外にもいくつかマウントしていて、/rootとして %LocalAppData%\lxss\root をマウントし、/homeとして%LocalAppData%\lxss\homeがマウントされます。これはWSLがアンインストールされてもそれらのフォルダは削除されないので、ユーザーファイルを保護することが出来ます。
これらのすべてのポイントはストレージが、Windowsのユーザーフォルダ内のディレクトリを使用してマウントされていることに注意してください。各Windowsユーザーは、自分のWSL環境を有しているので、Linuxのルート権限を持っているし、他のWindowsユーザーに影響を与えることなく、アプリケーションをインストールすることができます。
Inodes and file objects
Windowsは全くinodeとそれに関連する概念がないので、volfsはiノードに、Windowsのファイルオブジェクトへのハンドルを保持する必要があります。 VFSがルックアップコールバックを使用してあたらしい要求をしたとき、VolFsは親inodeからのハンドルを使用して、相対的に子の名前を取得して、新しいinodeのハンドルを取得します。これらのハンドルはファイルへの読み書きのアクセス無しに開かれ、メタデータ要求に対してのみに使用されます。
Emulating Linux features
簡単にまとめるとNTFSで足りていないものはVolFsがエミュレーションするか機能を提供すると言う事です。そして、NTFSに無いファイルのメタデータはNTFSのEA(EAレコード)として保存されます。(こりゃまた懐かしいものがｗ)
Interoperability with Windows
volfsファイルが上記のディレクトリにWindows上で通常のファイルに格納されていますが、Windowsとの相互運用性がサポートされていません。このためWindowsのエディタから直接volfsのファイルを編集してしまうと、Windowsエディタの多くがEAをサポートしていないので、保存時にEAを削除して問題を起こしてしまいます。
DrvFs
Windowsとの相互運用性を容易にするために、WSLがDrvFsファイルシステムを使用しています。 WSLは自動的にサポートしているファイルシステムの固定ディスクを/mntの下に、/mnt/c, /mnt/d等としてマウントします。現在、NTFSとReFsがサポートされています。
DrvFs permissions
簡単にまとめると以下のようになります。
- DrvFsではWindowsのファイルアクセス権限が使用されるよ
- bash.exeの実行権限に依存するのでsudoしてもアクセスできない場所があるよ。UACの昇格の有る無しでアクセスできる出来ないが発生するよ。
- アクセス権限が必ずしも1:1で対応できているわけでないよ。でも一応計算して出来るだけ対応するようにしている。
Case sensitivity
まとめると。
DrvFsはNTFSの元々の機能を使用して大文字と小文字を区別したファイルをサポートしているけど、Windowsのアプリケーションは区別できないから注意してね。ただドライブのルートでは禁止しているので必ずその下のディレクトリを作ってね。
Symbolic links
NTはシンボリックリンクをサポートしていますがWSLによって作成されたシンボリックリンクはWindowsでは意味を持たない/procのようなパスを指している可能性があるため、私たちはこのサポートに頼ることができませんでした。また、NTは、シンボリックリンクを作成するには、管理者権限が必要です。このため、我々は別の方法を見つけなければなりませんでした。
VolFsとは異なり、我々はファイルがDrvFsにシンボリックリンクであることを示すためにEAに頼ることができませんでした。その代わりに、WSLは、シンボリックリンクを実現するために新しいリパースポイントを使用しています。その結果、これらのリンクは、WSLの内側にのみ機能し、エクスプローラやcmd.exeのようなWindowsのコンポーネントから使用する事は出来ません。（ワオ！）また、ReFsではリパースポイントのサポートがないので、シンボリックリンクのサポートがないことに注意してください。NTFSでは完全にWSLのシンボリックリンクをサポートされます。
Interoperability with Windows
VolFsとは異なり、DrvFsは、任意の追加情報を格納しません。代わりに、すべてのinodeの属性が照会ファイル属性、有効なアクセス許可、およびその他の情報によって、NTで使用される情報から導出されています。 DrvFsはまた、常にWindowsプロセスは、ディレクトリの内容を変更した場合でも、正しい、最新の情報を提供し保証するために、ディレクトリエントリのキャッシュを無効にします。このように、DrvFsは彼らに動作している間、Windowsのプロセスはファイルに何ができるかに制限はありません。
DrvFsはファイルに対してWindowsのデリートセマンティクスを使用するので、ファイルが開かれている場合にはリンクを解除することが出来ません。
ProcFs and SysFs
Linuxでのように、これらの特殊なファイルシステムは、ディスク上に存在するファイルを表示するのではなく、プロセス、スレッド、およびデバイスについてのカーネルによって保持される情報を表すものではありません。読んだときにこれらのファイルは、動的に生成されます。いくつかのケースでは、ファイルの情報がlxcore.sysドライバ内部に完全に保持されます。このようなプロセスのCPU使用率などの他の例では、WSLはこの情報のためのNTカーネルを照会します。しかし、Windowsのファイルシステムとここには相互作用はありません。
まとめ
今後も改善していくのでGitHub等でフィードバックしてください。
感想
もうなんかお疲れ様でしたとしか言いようが無いｗただシンボリックリンクに関してはやはりNTFSの実装が中途半端すぎた感じですね。
[amazonjs asin=”4900900702″ locale=”JP” tmpl=”Small” title=”Windows NT ファイルシステム詳説―A Developer’s Guide”]
