BOOK Preview インサイドMicrosoft Windows 第4版 下 第10章 ストレージ管理 10.3.4 ボリューム名前空間 マイクロソフトプレスの書籍紹介ページ 書籍情報のページ 2005/11/29

本コーナーは、Windowsシステム管理者向けの書籍から、主要なチャプターをそのまま転載し、その内容を紹介するものです。 　今回ご紹介する『インサイドWindows 第4版』は、Windowsオペレーティング・システムの内部を詳細に解説した決定版です。Windowsカーネルの内部について、ここまで詳しく解説した情報はほかにありません。 　著者の1人であるデビット・ソロモン氏は、Windows NTの開発リーダーだったデビット・カトラー氏とは旧知の仲で、本書の前々版（『インサイドWindows NT 第2版』）を執筆するにあたり、Windowsカーネルのソースコードにアクセスする許可をカトラー氏から与えられました。それだけでなく、デビッド・カトラー氏は、本書の一部（プロセス管理の部分）について、技術校閲も担当しています。 　またもう1人の筆者であるマーク・ルシノビッチ氏は、Windowsオペレーティング・システムの機能を縦横に駆使したツール開発者として著名で、前出のカトラー氏も一目置く存在です。「かゆいところに手が届く」彼のツールは、多くのWindowsエンジニアにとって不可欠な存在となっています（フリー・ツールの入手先はこちら：SysInternals）。 　つまり本書は、Windowsコア・システムの開発責任者と、OS解説のエキスパートが、二人三脚で執筆し、Windowsの歴史とともに改版を重ねてきた希有な書籍なのです。今回の第4版では、Windows XPとWindows Server 2003に加えられたカーネルの変更点や、Windowsの64bitサポートなどについて加筆されています。情報システムの設計者やシステム管理者など、作り手や管理者としてWindowsシステムに接する必要があるなら、本書にまとめられた情報が仕事の随所で役立つはずです。 　本稿は、Windowsの内部構造や仕組みを解説した名著で最新の第4版です。Windows 2000、Windows XP、そしてWindows Server 2003に対応し、マルチプロセッサ、64ビットWindowsまで網羅しています。下巻は、Windowsのセキュリティ構造、I/Oシステムのコンポーネント、ストレージ管理、キャッシュマネージャの主な特徴について、さらにWindowsのファイルシステムとネットワーク構造、クラッシュダンプ解析について詳細に解説しています。 　なお、書籍の詳細については書籍情報のページをご覧ください。

ご注意：本記事は、書籍の内容を改訂することなく、そのまま転載したものです。このため用字用語の統一ルールなどは＠ITのそれとは一致しません。あらかじめご了承ください。

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はボリュームのデータベースエントリ内のドライブ文字ヒントを探します。

図10-14 マウントマネージャレジストリキーとマウント済みデバイス

　マウントマネージャは、ドライブ文字の提案がない場合には、最初の未割り当てドライブ文字を採用し、新規割り当てを定義します。そして、その割り当て文字へのシンボルリンクを作成し（たとえば、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が簡単にマウントポイントを列挙できるようにしているのです。

実験：再帰的なマウントポイント 　この実験では、www.sysinternals.comからダウンロードできるFilemonを使用し、再帰的なマウントポイントが引き起こす興味深い振る舞いを調べます。再帰的なマウントポイントというのは、自身が置かれているボリュームにリンクしているマウントポイントを指しています。再帰的なマウントポイント上で再帰的なディレクトリ検索を行うと、NTFSとマウントポイントの関係をはっきり示してくれるファイルアクセストレース情報を取得できます。 　次のような手順でマウントポイントを作成し、確認します。 コマンドプロンプトかWindowsエクスプローラを表示し、\Recurseという名称のディレクトリをNTFSドライブに作成する。 ディスク管理MMCスナップインで、ボリュームを右クリックし、［ドライブ文字とパスの変更］を選択する。 表示されるダイアログボックスから作成したディレクトリへのパスを入力する（たとえば、I:Recurse）。 Filemonを起動し、［Drives］メニューから作成したマウントポイントを除く、すべてのボリュームを無効にする。 　以上の作業を終了すれば、再帰的なマウントポイントトレース情報を作成できるようになります。コマンドプロンプトを表示し、dir/sI:\Recurseと入力します。Filemonのトレース情報内のRecurseを参照するすべてのファイルアクセスを見ると、コマンドプロンプトは最初にI:\Recurseにアクセスし、次にI:\Recurse\Recurseなどにアクセスしていることに気付くはずです。アクセスは再帰的に繰り返され、どんどん深まっていきます。 　アプリケーションは、すべての再帰レベルでディレクトリリストを検索しようとしますが、マウントポイントを検出すると、その中に入り込み、もう1つ別のディレクトリリストの検索を試みます。既に説明したように、NTFSはリパース状態コードを返します。このコードは、実は、オブジェクトマネージャにそのレベルのバックアップを取り、再試行を命じているのです。このため、最終的にルートディレクトリに戻ると、アプリケーションはマウントポイント再帰検索の深い方で見つけたファイルやディレクトリを調べます。アプリケーション自身は、オブジェクトマネージャが再試行を指示するため、リパースコードを決して受け取りません。オブジェクトマネージャは、ディレクトリ検索時には、NTFSからリパースコードを受信しながら、それを処理しているのです。 　Filemonは、要求タイプを自身にネイティブなIRPタイプとして表示してきますから、ディレクトリやファイルオープンはIRP_MJ_CREATE要求になります。ファイルやディレクトリのクローズは、IRP_MJ_CLOSEとなります。そして、ディレクトリ問い合わせは、Filemonの［Other］欄にFileBothDirectoryInfo付きのIRP_MJ_DIRECTORY_CONTROL要求として表示されます。 　バッファオーバーフローと無限ループを防止するため、コマンドプロンプトとWindowsエクスプローラはいずれもディレクトリの深さが32に達した時点で再帰動作を停止します。あるいは、パス名が256文字を超えた時点で動作を停止しています。2つの停止条件は、早く満たされた方が採用されます。

■ボリュームのマウント

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

注
Windows Server 2003 EnterpriseとDatacenter Editionでは、ボリュームの自動マウントはSAN（System Area Network）に多量のボリュームがマウントされるのを防止するために無効にしています（つまり、ボリュームマネージャがボリュームの存在を報告しても自動的にマウントされません）。Windows Server 2003に付属するDiskpartコマンドラインユーティリティを使用すると、自動マウント機能の有効/無効の切り替えを行うことができます。また、Mountvolユーティリティを使用すれば、ボリュームをマウントできます。

　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マネージャは登録済みファイルシステムドライバそれぞれにマウント要求を送り、現在問題となっているボリュームのフォーマットを認識できるかどうかを尋ねます。

実験：VPBを調べる 　VPBの内容を調べる場合には、カーネルデバッガコマンドの!vpbが使えます。VPBへのポインタは、ボリュームのデバイスオブジェクト内に含まれていますから、まず、ボリュームデバイスオブジェクトを特定する必要があります。この作業では、ボリュームマネージャのドライバオブジェクトをダンプ出力し、ボリュームを表現するデバイスオブジェクトを特定する必要があります。そして、VPBフィールドを持つデバイスオブジェクト情報を表示させます。 　システム内でダイナミックディスクを使用している場合には、!drvobjドライバオブジェクト表示コマンドをDMIOドライバ上で実行できます。使用していない場合には、次のようにFtDiskドライバに対してコマンドを実行します。 kd> !drvobj ftdisk Driver object (818aec50) is for: \Driver\Ftdisk Driver Extension List: (id , addr) Device Object list: 818a5290  817e96f0  817e98b0  817e9030 818a73b0  818a7810  8182d030 　!drvobjコマンドは、ドライバが所有するデバイスのアドレスを表示してきます。この例では、7個のデバイスオブジェクトが返されています。そのうちの1つはデバイスドライバへのプログラムインターフェイスを表現し、残りはボリュームデバイスオブジェクトとなっています。オブジェクトは、最後に作成されたオブジェクトからリスト表示されています。ドライバは、デバイスドライバインターフェイスを最初に作成することになっています。このため、最初にリストされるデバイスオブジェクトは、ボリュームのデバイスオブジェクトです。これらの知識を活かし、!devobjカーネルデバッガコマンドを次のように実行します。 kd> !devobj 818a5290 Device object (818a5290) is for:   HarddiskVolume6 \Driver\Ftdisk DriverObject 818aec50 Current Irp 00000000 RefCount 3 Type 00000007 Flags 00001050 Vpb 818a5da8 Dacl e1000384 DevExt 818a5348 DevObjExt 818a53f8 Dope 818a50a8   DevNode 818a5ae8 ExtensionFlags (0xa8000000) DOE_RAW_FDO, DOE_DESIGNATED_FDO                             Unknown flags 0x08000000 AttachedDevice (Upper) 86b52b58 \Driver\VolSnap Device queue is not busy. 　!devobjコマンドは、ボリュームデバイスオブジェクトのVPBフィールドを表示します（この例では、デバイスオブジェクトはHarddiskVolume6という名前を持っています）。ここまでの情報を入手できれば、!vpbコマンドを使用できるようになります。 kd> !vpb 818a5da8 Vpb at 0x818a5da8 Flags:        0x1 mounted DeviceObject: 0x850dcac0 RealDevice:   0x818a5290 RefCount:     3 Volume Label: BACKUP 　このようにボリュームデバイスオブジェクトは、ボリュームにBACKUPという名前を割り当てたファイルシステムドライバによってマウントされています。VPB内のRealDeviceフィールドはボリュームデバイスオブジェクトへの逆参照であり、DeviceObjectフィールドはマウントされているファイルシステムデバイスオブジェクトを指しています。

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

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

図10-15 マウント済みボリュームへのI/Oの流れ

　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ファイルシステムドライバは、ディスクのボリューム識別子を問い合わせることにより、メディア変更に応じた処理を行います。ボリューム識別子が変更されたことを認識すると、ドライバはディスクをアンマウントし、再度マウントします。

INDEX
	インサイドMicrosoft Windows 第4版 下
	第10章 ストレージ管理
	10.1 ストレージ関連用語／10.2 ディスクドライバ／10.2.1 Ntldr
	10.2.2 ディスククラス、ポート、およびミニポートドライバ／10.2.3 ディスクデバイスオブジェクト／10.2.4 パーティションマネージャ
	10.3 ボリューム管理／10.3.1　基本ディスク
	10.3.2 ダイナミックディスク
	10.3.3 マルチパーティションボリューム管理
	10.3.4 ボリューム名前空間NEW!
	10.3.5 ボリュームI/O処理／10.3.6 仮想ディスクサービス（VDS）／10.3.7 ボリュームシャドウコピーサービス／まとめNEW!

　

「BOOK Preview」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）