10.3.4 ボリューム名前空間

　ドライブ文字の割り当て方法は、Windows NT 4からWindows 2000の流れの中で大きく変化した、ストレージ管理の一面です。しかし、Windowsは、Windows NT 4で行われたドライブ文字割り当ての移植をサポートする機能を提供しています。Windows NT 4ドライブ文字割り当ては、HKLM¥SYSTEM¥Diskに格納されています。アップグレードプロシージャは情報を読み取り、Windows固有の位置に格納し、システムはそれ以降、Diskキー内容を参照することはありません。

■マウントマネージャ

　マウントマネージャデバイスドライバ（Mountmgr.sys）は、Windowsインストール後に作成されるダイナミックボリュームや基本ディスクボリューム（たとえば、CD-ROM、フロッピー、およびリムーバルメディア）にドライバ文字を割り当てます。Windowsは、すべての割り当て済みドライブ文字を¥HKLM¥SYSTEM¥MountedDevicesレジストリキーに格納します。そのキーを覗いてみるとわかりますが、「¥??¥Volume{X}（XにはGUID）」などの名前を持つ値と「¥DosDevices¥C:」のような値が格納されています。すべてのボリュームは、名前エントリを持っていますが、割り当て済みドライブ文字を持っているとは限りません。図10-14は、マウントマネージャレジストリキーの例を示しています。注意して見てみると、MountedDevicesキーは、Windows NT 4と同じように、コントロールセットに含まれていません。また、最後に正常実行されたブートオプションによって保護されていません（コントロールセットとブートオプションについては、「4.2.6ブート処理とLast Known Goodの受け入れ」を参照してください）。

　基本ディスクボリュームドライブ文字とボリューム名のレジストリ値に格納されるデータは、Windows NT 4スタイルのディスクシグネチャとそのボリュームに関連する第1パーティションの開始オフセットです。ダイナミックディスクボリュームのレジストリ値に格納されるデータは、ボリュームのDMIO内部GUIDです。マウントマネージャはブートプロセスの初期化時、Windows PnPマネージャに自分自身を登録します。この登録により、マウントマネージャは、FtDiskやDMIOのいずれかがボリュームを作成したときに、その旨の通知を受け取れるようになります。マウントマネージャがその種の通知を受け取ると、新しいボリュームGUIDやディスクシグネチャを決定し、それを頼りに内部データベース（MountedDevicesレジストリキー）を検索します。その後、マウントマネージャは、内部データベースがドライブ文字を含んでいるかどうかを決定します。データベースに存在しない場合、マウントマネージャは（ボリュームを作成した）FtDiskかDMIOのいずれかにドライブ文字の割り当て提案を要求し、それをデータベースに格納します。実際には、FtDiskは提案を返すことはなく、DMIOはボリュームのデータベースエントリ内のド� ��イブ文字ヒントを探します。

どのようにベストプラクティスシステムを設定しない

　マウントマネージャは、ドライブ文字の提案がない場合には、最初の未割り当てドライブ文字を採用し、新規割り当てを定義します。そして、その割り当て文字へのシンボルリンクを作成し（たとえば、Windows XPとWindows Server 2003では¥Global??¥D:など）、MountedDevicesレジストリキーを更新します。利用できるドライブ文字がない場合、ドライブ文字の割り当ては行われません。このような場合には、マウントマネージャは、新規ボリュームのGUIDを定義するボリュームシンボルリンク（つまり、¥Global??¥Volume{X}）を作成します。ここで作成されるGUIDは、DMIOが内部で使用するボリュームGUIDと異なるものです。

■マウントポイント

　「マウントポイント」は、NTFSボリューム上のディレクトリ経由でボリュームをリンクする技術です。この技術は、ドライブ文字が割り当てられていないボリュームへのアクセスも可能とします。たとえば、「C:¥Projects」という名前のNTFSディレクトリがあり、皆さんのプロジェクトディレクトリとファイルを含む別のボリューム（NTFSかFAT）をマウントできるとしましょう。皆さんのプロジェクトボリュームに¥CurrentProject¥Description.txtという名前のファイルを格納している場合、C:¥Projects¥CurrentProject¥Description.txtというパス経由でアクセスできるようになります。これは、マウントポイントは、第12章で詳述する「リパースポイント」技術であることを示しています。

　リパースポイントというのは、WindowsがNTFSディレクトリやファイルに関連付ける、いくつかの固定ヘッダーデータを持つ任意のデータブロックです。アプリケーションやシステムは、リパースポイントのフォーマットと振る舞いを定義します。この定義には、そのアプリケーションやシステムに属するリパースポイントを識別し、リパースポイントのデータ部分の大きさと意味を指定するタグを含めます（データ部分は16KBの大きさになることができます）。リパースポイントは、固有のタグを固定セグメントに格納します。リパースポイントを実装するすべてのアプリケーションは、ファイルシステムフィルタドライバを提供し、リパース関連戻り値をチェックし、NTFSボリューム上で実行されるファイル操作を監視する必要があります 。ドライバが戻り値を検出した場合には、適切な処理を行う必要があります。NTFSは、ファイル操作を実行し、関連するリパースポイントを持つファイルやディレクトリを検出した場合には、リパース状態コードを返す必要があります。

　Windows NTFSファイルシステム、I/Oマネージャ、およびオブジェクトマネージャは、すべて部分的にリパースポイント機能を実装しています。オブジェクトマネージャは、I/Oマネージャをインターフェイスとしてファイルシステムドライバと通信し、パス名解析処理を開始しています。このため、オブジェクトマネージャは、I/Oマネージャが返すリパース状態コードに応じて処理を再試行する必要があります。I/Oマネージャは、マウントポイントと他のリパースポイントが必要とするパス名修正コードを実装しているため、NTFSファイルシステムドライバはリパースポイントデータをファイルとディレクトリに関連付け、特定する必要があります。つまり、I/Oマネージャは、多くのMicrosoft定義のリパースポイント用のリパースポイントファイルフィル� �のようなものなのです。

　リパースポイントアプリケーションとしては、Windows 2000サーバーとWindows Server 2003に含まれるWindowsリモートストレージサービス（RSS）などの階層ストレージ管理（HSM）システムがあります。このようなシステムはリパースポイントを使用して、管理者がオフラインテープストレージに移動したファイルを指定しています。ユーザーがオフラインファイルにアクセスしようとすると、HSMフィルタドライバはNTFSから返されるリパース状態コードを検出し、ユーザーモードサービスと通信してオフラインストレージからファイルを取得し、ファイルからリパースポイントを削除します。その後、サービスがファイルを取得後、ファイル操作を再試行できるようにします。これはまさに、RSSフィルタドライバ（Rsfilter.sys）がリパースポイントを使用する過程そのものです。

　I/OマネージャがNTFSからのリパース状態コードを取得し、目的のファイルやディレクトリが内蔵のWindowsリパースポイントと関連付けられていない場合には、リパースポイントを削除するフィルタドライバがないことになります。この場合、I/Oマネージャはオブジェクトマネージャにエラーを返します。このエラーは最終的に、ファイルやディレクトリにアクセスを行っているアプリケーションに伝えられます。

　マウントポイントは、ボリューム名（¥Global??¥Volume{X}）をリパースデータとして格納するリパースポイントです。ディスク管理MMCスナップインを使用してボリュームへのパス割り当てを行ったり、解除するとき、それはマウントポイントを作成していることになります。また、内蔵のコマンドラインツールMountvol.exe（¥Windows¥System32¥Mountvol.exe）を使用すると、マウントポイントを作成したり、表示させることができます。

電話の拡張機能をインストールする方法

　マウントマネージャは、すべてのNTFSボリューム上にマウントマネージャリモートデータベースを作成し、管理しています。マウントマネージャは、そのデータベース内にボリューム用に定義された、すべてのマウントポイントを記録しています。データベースファイルは、$MountMgrRemoteDatabaseという名称を持ち、NTFSのルートディレクトリに置かれます。マウントポイントは、ディスクがシステムから別のシステムに移動すると、同じように移動します。また、複数のWindows間でブート切り替えが行われるデュアルブート環境でも移動します。この移動は、マウントマネージャがリモートデータベースを使用していることに起因しています。NTFSはまた、NTFSメタデータファイル¥$Extend¥$Reparseにマウントポイントの追跡情報を格納しています� �ただし、このファイル内容は、アプリケーションから見られないようになっています）。NTFSは、マウントポイント情報をメタデータファイルに記録することにより、ディスク管理などのWindowsアプリケーションがマウントポイント定義情報を要求してきたときに、Windowsが簡単にマウントポイントを列挙できるようにしているのです。

■ボリュームのマウント

　Windowsはボリュームにドライブ文字を割り当てますが、そのボリュームがWindowsが認識できるファイルシステムフォーマットを持つデータを記憶していることを意味するものではありません。ボリュームの認識プロセスは、ファイルシステムがパーティションの所有権を取得するプロセスでもあります。このプロセスは、カーネル、デバイスドライバ、あるいはアプリケーションがボリューム上のファイルやディレクトリに最初にアクセスしたときに開始されます。ファイルシステムドライバがパーティションの所有権を取得したことを通知すると、I/Oマネージャはボリュームに向けられたすべてのIRPをその所有者ドライバに送りつけます。Windowsのほとんどの動作は、ファイルシステムドライバ登録、ボリュームパラメータブロック（VPB� ��、およびマウント要求で構成されています。

　I/Oマネージャは、マウントプロセスを監視し、利用可能なファイルシステムドライバを認識しています（すべてのファイルシステムドライバは、初期化時にI/Oマネージャに登録されます）。I/Oマネージャは、登録機能を実装するIoRegisterFileSystem関数を（ネットワークではなく）ローカルディスクファイルシステムドライバに提供しています。ファイルシステムドライバが自分自身を登録すると、I/Oマネージャはそのドライバへの参照を、マウント時に使用するリストに格納します。

　すべてのデバイスオブジェクトはVPB構造体を持っていますが、I/OマネージャはボリュームデバイスオブジェクトのVPBのみを活用します。VPBは、ボリュームデバイスオブジェクトと、ファイルシステムドライバがボリューム用のマウント済みファイルシステムインスタンスを表現するために作成するデバイスオブジェクトの間のリンクとして機能します。VPBのファイルシステム参照が空の場合、ボリュームをマウントしているファイルシステムはありません。I/Oマネージャは、ボリュームデバイスオブジェクト上のファイル名やディレクトリ名を指定するAPIの実行時には必ず、ボリュームデバイスオブジェクトのVPBをチェックします。

　たとえば、マウントマネージャがドライブ文字Dをシステム内の第2ボリュームに割り当てる場合、¥Device¥HarddiskVolume2を指す¥Global??¥D:というシンボルリンクを作成します。Dドライブ上の¥Temp¥Test.txtファイルをオープンしようとするWindowsアプリケーションは、D:¥Temp¥Test.txtという名前を指定します。Windowsサブシステムは、カーネルのファイルオープンルーチンであるNtCreateFileを呼び出す前に、D:¥Temp¥Test.txtを¥Global??¥D:¥Temp¥Test.txtに変換します。NtCreateFileルーチンは、オブジェクトマネージャを使って名前を分析します。オブジェクトマネージャは、¥Temp¥Test.txtパス部分は未解決であっても、¥Device¥HarddiskVolume2デバイスオブジェクトを検出します。I/Oマネージャはこの時点で、¥Device¥HarddiskVolume2のVPBがファイルシステムを参照してい� ��かどうかをチェックします。参照していない場合、I/Oマネージャは登録済みファイルシステムドライバそれぞれにマウント要求を送り、現在問題となっているボリュームのフォーマットを認識できるかどうかを尋ねます。

　ファイルシステムドライバは、それぞれのフォーマットでマウントされたボリュームを認識します。この認識過程では、ボリュームのブートレコードが調べられます。ブートレコードは、ボリュームの第1セクタに格納されています。Microsoftファイルシステムのブートレコードは、ファイルシステムフォーマットタイプを記憶するフィールドを持っています。ファイルシステムドライバは通常、このフィールドを調べ、自分の認識できるフォーマットである場合には、ブートレコード内の他の情報を読みに行きます。読まれる情報には、ファイルシステム名フィールドがあります。ファイルシステムドライバは、その情報を頼りにボリューム上の重要なメタデータファイルを特定しています。たとえば、NTFSは、タイプフィール� ��がNTFS、名前フィールドがNTFS、そしてブートレコード内に記述されている重要なメタデータファイルに整合性がある場合にのみ、ボリュームを認識することになります。

　ファイルシステムドライバが前向きの信号（つまり、認識可能）を送ってくれば、I/OマネージャはVPBに必要データを書き込み、残りのパス（¥Temp¥Test.txt）と共に、オープン要求をファイルシステムドライバに渡します。ファイルシステムドライバは、ボリューム内に格納されているデータを自分のフォーマットを使って解釈し、要求を完了します。マウントファイルがボリュームデバイスオブジェクトのVPBに情報を設定すると、I/Oマネージャはボリューム向けの後続オープン要求をマウント済みファイルシステムドライバに渡します。ボリュームの所有者であるファイルシステムドライバがない場合には、Ntoskrnl.exe内に組み込まれている「生」のファイルシステムドライバがそのボリュームの所有権を取得し、ボリュームパーティショ ンに対するすべてのオープンファイル要求を失敗させます。図10-15は、マウント済みボリュームへのI/O要求が辿るパスを単純化したものです（ファイルシステムドライバとWindowsキャッシュ/メモリマネージャのかかわりなどは省略されています）。

　Windowsは、管理すべきボリュームの有無に関係なく、すべてのファイルシステムドライバをロードするわけではありません。Windowsは、メモリ使用を最小に抑えるため、ファイルシステムレコグナイザ（¥Windows¥System32¥Drivers¥Fs_rec.sys）という名前のサロゲート（代理）ドライバを用意し、ファイルシステムを認識する準備を行っています。代理ドライバは、Windowsがサポートするすべてのファイルシステムフォーマットを熟知したうえで、ブートレコードを調べる機能を実装しています。ブートレコード調査後、代理ドライバは、Windowsファイルシステムドライバとの関係を判断します。システムのブート時、代理ドライバは自分自身をファイルシステムドライバとして登録し、新しいボリュームのファイルシステムをマウントするときに� �I/Oマネージャから呼び出されます。この呼び出しでは、代理ドライバはブートレコードを参照しながら、まだロードされていない適切なファイルシステムドライバをロードします。ファイルシステムドライバのロード後は、マウントIRPはそのドライバに配送され、ファイルシステムドライバがそのボリュームの所有者になります。

　カーネル初期化時にマウントされるブートボリュームは別にして、ファイルシステムドライバは、ブートシーケンス内でChkdskファイルシステム整合性チェックアプリケーションが動作するときに、ほとんどのボリュームをマウントします。ブート時のChkdskバージョンは、Autochk.exe（¥Windows¥System32¥Autochk.exe）という名称を持つ、（Windowsアプリケーションではなく）ネイティブアプリケーションです。このアプリケーションは、ブート時に実行されるアプリケーションの1つとしてHKLM¥SYSTEM¥CurrentControlSet¥Control
¥SessionManager¥BootExecute値に指定されているため、セッションマネージャ（¥Windows¥System32¥Smss.exe）が起動します。Chkdskはそれぞれのドライブ文字にアクセスし、関連付けられているボリュームが整合性チェックを必要としているかどうかを決定します。

　リムーバルメディアの場合には、同一ディスクに対して複数回のマウント処理が行われます。Windowsファイルシステムドライバは、ディスクのボリューム識別子を問い合わせることにより、メディア変更に応じた処理を行います。ボリューム識別子が変更されたことを認識すると、ドライバはディスクをアンマウントし、再度マウントします。

TechTargetジャパン

キャリアアップ