(57)【要約】【課題】ファイル・システム・メタデータを生成するためのコンピュータ実施方法、コンピュータ使用可能コード、および機器を提供すること。【解決手段】プロセッサは、ファイル・システム・メタデータを選択する。プロセッサは、ファイル・システムにおいて各データ単位を識別する。プロセッサは、データ単位がファイル・システム・メタデータを含むかどうかを判定する。データ単位がファイル・システム・メタデータを含むと判定された場合、プロセッサは、メタデータのデータ単位を診断ファイルに書き込む。次にプロセッサは、データ単位がユーザ・データを含むかどうかを判定する。データ単位がユーザ・データを含む場合、プロセッサは、スパース・オブジェクトを診断ファイルに書き込む。【選択図】図１
2007095064.tif 000002
【特許請求の範囲】
【請求項１】
ファイル・システム・メタデータを生成するためのコンピュータ実施方法であって、
ファイル・システムにおいて複数のデータ単位を識別するステップと、
前記複数のデータ単位のうちのデータ単位がファイル・システム・メタデータを含むかどうかを判定するステップと、
前記データ単位が前記ファイル・システム・メタデータを含むとの判定に応答して、前記ファイル・システム・メタデータを前記データ単位から診断ファイル・システムに書き込むステップと、
前記データ単位がユーザ・データを含むかどうかを判定するステップと、
前記データ単位がユーザ・データを含むとの判定に応答して、スパース・オブジェクトを前記ファイル・システム・メタデータに関連する診断ファイルに書き込むステップとを含む、ファイル・システム・メタデータを生成するためのコンピュータ実施方法。
【請求項２】
前記診断ファイルを前記診断ファイル・システムに関連付けるステップと、
前記診断ファイル・システムをマウントするステップとをさらに含む、請求項１に記載のファイル・システム・メタデータを生成するためのコンピュータ実施方法。
【請求項３】
前記診断ファイルを稠密診断データに統合するステップをさらに含む、請求項１に記載のファイル・システム・メタデータを生成するためのコンピュータ実施方法。
【請求項４】
統合するステップが、
前記診断ファイルを前記診断ファイル・システムに保存するステップと、
前記診断ファイル・システムを圧縮するステップとをさらに含む、請求項３に記載のファイル・システム・メタデータを生成するためのコンピュータ実施方法。
【請求項５】
前記稠密診断データを送信するステップをさらに含む、請求項３に記載のファイル・システム・メタデータを生成するためのコンピュータ実施方法。
【請求項６】
統合するステップが、
前記診断ファイル・システムをファイルとして保存するステップと、
前記ファイルを圧縮して前記稠密診断データを形成するステップとをさらに含む、請求項５に記載のファイル・システム・メタデータを生成するためのコンピュータ実施方法。
【請求項７】
前記診断ファイル・システムを生成するステップと、
前記診断ファイル・システムをマウントするステップとをさらに含む、請求項５に記載のファイル・システム・メタデータを生成するためのコンピュータ実施方法。
【請求項８】
統合するステップが、
前記診断ファイル・システムをファイルとして保存するステップと、
前記ファイルを稠密診断データに圧縮するステップとをさらに含む、請求項７に記載のファイル・システム・メタデータを生成するためのコンピュータ実施方法。
【請求項９】
データ単位がブロックを含む、請求項８に記載のファイル・システム・メタデータを生成するためのコンピュータ実施方法。
【請求項１０】
判定する前記ステップと、前記スパース・オブジェクトを書き込む前記ステップとが、前記複数のデータ単位のうちの各データ単位について繰り返される、請求項１に記載のファイル・システム・メタデータを生成するためのコンピュータ実施方法。
【請求項１１】
バスと、
前記バスに接続され、コンピュータ使用可能コードが配置される記憶装置と、
前記バスに接続される通信ユニットと、
前記バスに接続される処理ユニットであって、ファイル・システム・メタデータを生成するコンピュータ使用可能コードを実行し、さらにファイル・システムにおいて複数のデータ単位を識別し、データ単位がファイル・システム・メタデータを含むかどうかを判定し、前記データ単位が前記ファイル・システム・メタデータを含むとの判定に応答して、前記ファイル・システム・メタデータを前記データ単位から診断ファイル・システムに書き込み、前記データ単位がユーザ・データを含むかどうかを判定し、前記データ単位がユーザ・データを含むとの判定に応答して、スパース・オブジェクトを前記ファイル・システム・メタデータに関連する診断ファイルに書き込むコンピュータ使用可能コードを実行する処理ユニットとを含む、データ処理システム。
【請求項１２】
前記処理ユニットがさらに、前記診断ファイルを前記診断ファイル・システムに関連付け、前記診断ファイル・システムをマウントするコンピュータ使用可能コードを実行する、請求項１１に記載のデータ処理システム。
【請求項１３】
前記処理ユニットがさらに、前記診断ファイルを稠密診断データに統合するコンピュータ使用可能コードを実行する、請求項１１に記載のデータ処理システム。
【請求項１４】
統合するコンピュータ使用可能コードの実行において、前記処理ユニットがさらに、前記診断ファイルを前記診断ファイル・システムに保存し、前記診断ファイル・システムを圧縮するコンピュータ使用可能コードを実行する、請求項１３に記載のデータ処理システム。
【請求項１５】
前記処理ユニットがさらに、前記稠密診断データを送信するコンピュータ使用可能コードを実行し、統合するコンピュータ使用可能コードの実行において、前記処理ユニットがさらに、前記診断ファイル・システムをファイルとして保存し、前記ファイルを圧縮して稠密診断データを形成するコンピュータ使用可能コードを実行する、請求項１３に記載のデータ処理システム。
【請求項１６】
前記処理ユニットがさらに、診断ファイル・システムを生成し、前記診断ファイル・システムをマウントするコンピュータ使用可能コードを実行する、請求項１５に記載のデータ処理システム。
【請求項１７】
統合するコンピュータ使用可能コードの実行において、前記処理ユニットがさらに、前記診断ファイル・システムをファイルとして保存し、前記ファイルを稠密診断データに圧縮するコンピュータ使用可能コードを実行する、請求項１６に記載のデータ処理システム。
【請求項１８】
前記処理ユニットがさらに、判定するコンピュータ使用可能コードを前記複数のデータ単位のうちの各データ単位について繰り返し実行し、また前記データ単位が前記ファイル・システム・メタデータを含むとの判定に応答して、ファイル・システム・メタデータを前記データ単位から書き込むコンピュータ使用可能コードを繰り返し実行するコンピュータ使用可能コードを実行する、請求項１１に記載のデータ処理システム。
【請求項１９】
ファイル・システム・メタデータを生成するための機器であって、
ファイル・システムにおいて複数のデータ単位を識別する手段と、
横断する手段に結合された、前記データ単位がファイル・システム・メタデータを含むかどうかを判定する手段と、
前記データ単位が前記ファイル・システム・メタデータを含むと判定した手段に応答して、前記ファイル・システム・メタデータを前記データ単位から診断ファイル・システムに書き込む手段と、
メタデータの単位を診断ファイルに書き込む前記手段に結合された、前記データ単位がユーザ・データを含むかどうかを判定する手段と、
前記データ単位がユーザ・データを含むと判定した手段に応答して、スパース・オブジェクトを前記ファイル・システム・メタデータに関連する診断ファイルに書き込む手段とを含む、ファイル・システム・メタデータを生成するための機器。
【請求項２０】
前記診断ファイルを前記診断ファイル・システムに関連付ける手段と、
前記診断ファイル・システムをマウントする手段とをさらに含む、請求項１９に記載のファイル・システム・メタデータを生成するための機器。
【請求項２１】
前記診断ファイルを稠密診断データに統合する手段をさらに含む、請求項１９に記載のファイル・システム・メタデータを生成するための機器。
【請求項２２】
統合する手段が、
前記診断ファイルを前記診断ファイル・システムに保存する手段と、
前記診断ファイル・システムを前記稠密診断データに圧縮する手段とをさらに含む、請求項２１に記載のファイル・システム・メタデータを生成するための機器。
【請求項２３】
前記稠密診断データを送信する手段をさらに含む、請求項２１に記載のファイル・システム・メタデータを生成するための機器。
【請求項２４】
統合する手段が、
前記診断ファイル・システムをファイルとして保存する手段と、
前記ファイルを圧縮して前記稠密診断データを形成する手段とをさらに含む、請求項２３に記載のファイル・システム・メタデータを生成するための機器。
【請求項２５】
前記診断ファイル・システムを生成する手段と、
前記診断ファイル・システムをマウントする手段とをさらに含み、統合する手段が、
前記診断ファイル・システムをファイルとして保存する手段と、
前記ファイルを稠密診断データに圧縮する手段とをさらに含む、請求項２３に記載のファイル・システム・メタデータを生成するための機器。
【請求項２６】
判定する前記手段と、前記スパース・オブジェクトを書き込む前記手段とを繰り返し利用する手段をさらに含む、請求項１９に記載のファイル・システム・メタデータを生成するための機器。
【請求項２７】
ファイル・システムにサービス提供するための方法であって、
前記ファイル・システムから診断ファイル・システムを生成するためのコンピュータ使用可能プログラム・コードを顧客に送るステップであって、前記コンピュータ使用可能プログラム・コードは、ファイル・システム・メタデータを前記ファイル・システム・メタデータを含む各データ単位から診断ファイル・システムに書き込み、ユーザ・データを含む各データ単位についてスパース・オブジェクトを診断ファイルに書き込み、診断ファイルは前記ファイル・システム・メタデータに関連するステップと、
前記診断ファイル・システムを顧客から受け取るステップと、
前記診断ファイル・システムにサービス提供して、サービス済ファイル・システムを形成するステップと、
前記サービス済ファイル・システムを前記顧客に返送するステップとを含む、方法。
【請求項２８】
サービス提供する前記ステップが、
前記診断ファイル・システムにおいて保守を実行して、前記サービス済ファイル・システムを形成するステップを含む、請求項２７に記載の方法。
【請求項２９】
サービス提供する前記ステップが、
前記診断ファイル・システムにおいて回復動作を実行して、前記サービス済ファイル・システムを形成するステップを含む、請求項２７に記載の方法。
【請求項３０】
前記診断ファイル・システムにサービス提供した際に提供されたサービスについて前記顧客に請求を行うステップをさらに含む、請求項２７に記載の方法。
【請求項３１】
ファイル・システム・メタデータを生成するコンピュータ使用可能プログラム・コードを有するコンピュータ使用可能媒体を含むコンピュータ・プログラムであって、
ファイル・システムにおいて複数のデータ単位を識別するコンピュータ使用可能プログラム・コードと、
前記データ単位がファイル・システム・メタデータを含むかどうかを判定するコンピュータ使用可能プログラム・コードと、
前記データ単位が前記ファイル・システム・メタデータを含むとの判定に応答して、前記ファイル・システム・メタデータを前記データ単位から診断ファイル・システムに書き込むコンピュータ使用可能プログラム・コードと、
前記データ単位がユーザ・データを含むかどうかを判定するコンピュータ使用可能プログラム・コードと、
前記データ単位がユーザ・データを含むとの判定に応答して、スパース・オブジェクトを前記ファイル・システム・メタデータに関連する診断ファイルに書き込むコンピュータ使用可能プログラム・コードとを含む、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、ファイル・システムの整合性を維持および改善することに関する。より詳細には、本発明は、ファイル・システム・メタデータを稠密フォーマットで取得して、そのようなデータが専門家の検査および修復のために現地外に送られ得るようにするための方法、機器、およびコンピュータ使用可能コードに関する。
【背景技術】
【０００２】
コンピュータ分野では、ファイル・システムは、ファイルを見つけアクセスし易くするように、コンピュータ・ファイルおよびそれらが含むデータを保存し組織化するための構造である。ファイル・システムは、ハード・ディスクまたはＣＤ−ＲＯＭなどの記憶装置を使用することができ、ファイルの物理的ロケーションを維持することを必要とする。代替として、ファイル・システムは、仮想ファイル・システムとすることができる。仮想ファイル・システムは、仮想データまたはネットワークを介したデータへのアクセス方法としてのみ存在する。
【０００３】
ファイル・システムは、２つのタイプのデータから作成される。通常大部分を占める第１のタイプのデータは、ユーザ・データである。ユーザ・データの内容タイプは、例えば、テキスト、グラフィックス、音楽、およびコンピュータ命令とすることができる。第２のタイプのデータは、ファイル・システム・メタデータである。ファイル・システム・メタデータは、ユーザ・データ以外のすべてのデータである。メタデータは、ユーザ・データを含むファイルの統計および構造を処理システムに通知する。
【０００４】
ファイル・システム・メタデータは、スーパーブロックを含み、スーパブロックは、ファイル・システム概要を提供し、その他の情報へのポインタを含む。ｉノードは、各ファイルに関連付けられたファイル・システム・メタデータである。ｉノードは、バイト数によるファイル長、関連装置識別子、ユーザ識別子、グループ識別子、一意とし得るｉノード番号、ファイル・モード、タイムスタンプ、および参照カウントを示す。
【０００５】
ブロックは、ファイルに割り当てられ得る最小単位のディスク記憶である。例えば、プロセッサは、特定のファイル・システムにおいて、１ブロックを１０２４バイトに設定することができる。これは、ファイルがほぼ常に１つまたは複数のブロックを満たし、最終ブロックはデータによって部分的にのみ占有されることを意味する。
【０００６】
ファイルの部分は、複数のブロックに存在することができ、時にはディスク・ドライブ内に散在させられる。ｉノードは、ｉノード内で複数のブロックを列挙することができる。より大きなファイルの場合、ｉノードは、間接ブロックを含むことができ、間接ブロックは、さらなるブロックの列挙をポイントすることができる。しばしば、これは、後続のより深いブロックの層をポイントする多数のレベルの間接ブロックからなるツリー状構造を生じさせる。
【０００７】
ファイル・システムは、非常に大きなデータ構造になる傾向にある。プロセッサがファイル・システムに変更を加える場合、プロセッサはしばしば、多くの別個の書き込み操作を必要とする。ときには、エラーまたはその他の障害、例えば、電源障害の発生などは、一連の書き込みを途中で妨げることがある。
【０００８】
こうした状況でプロセッサがエラーに遭遇すると、競合条件が発生することがある。競合条件は、１つの電子装置における２つのイベントが、どちらが装置の状態または出力に影響を与えるかを見るために互いに本質的に競合するときに発生するものであり、その場合、最初に到着したイベントまたは信号が、装置の状態を制御する。ジャーナル・ファイル・システムなどのファイル・システムの文脈では、ファイル・システムを更新する場合、１）ファイルのディレクトリ・エントリを削除し、２）そのファイルのｉノードを空きスペース・マップ内で空きスペースとして印付けるという２つのステップが発生する。
【０００９】
電源が障害を起こし、ステップ１がクラッシュの直前に発生した場合、親のないｉノードが存在するようになり、実際に割り当てられているよりも多くのブロックが、記憶装置に割り当てられているように見える。ステップ２がクラッシュの直前に発生した場合、まだ削除されていないｉノードが空きとして印付けられ、おそらく何か他のものによって上書きされることになる。
【００１０】
特定のタイプのファイル・システムであるジャーナル・ファイル・システムは、さらなる障害モードを有する。上で述べられた２つのステップに加えて、ジャーナル・ファイル・システムは、トランザクションのために行われた変更をコミットする第３のステップを有する。ものごとが正常に機能した場合、プロセッサは、すべてのトランザクションをジャーナル・ログにコミットするが、さもなければ、すべてのトランザクションをジャーナル・ログにコミットしない。ジャーナル・ファイル・システムでは、プロセッサは、メタデータを整合性のある状態に確立するため、ジャーナル・ログを再実行することができる。しかし、ジャーナル・ファイル・システムは、ある書き込みが失敗したのに、プロセッサがトランザクションのその他の部分をジャーナル・ログに書き込んだときに発生するようなＩ／Ｏエラー・ハンドリングの失敗が起こると、不整合になることがある。
【００１１】
ファイル・システムの保守および回復を遠隔地にアウトソーシングすることに伴う危険は、送られるファイル・システムの詳細が傍受され得ることである。これは、データがインターネットを介して送信される場合に特に当てはまる。暗号化データであっても、傍受されれば、危険にさらされ得る。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
したがって、可能であればインターネットを介した機密情報の送信を回避することが長年にわたって望まれている。
【課題を解決するための手段】
【００１３】
本発明の態様は、ファイル・システム・メタデータを生成するためのコンピュータ実施方法、コンピュータ使用可能コード、および機器を提供する。プロセッサは、ファイル・システムにおいて各データ単位を識別する。プロセッサは、データ単位がファイル・システム・メタデータを含むかどうかを判定する。データ単位がファイル・システム・メタデータを含むと判定された場合、プロセッサは、メタデータのデータ単位を診断ファイルに書き込む。次にプロセッサは、データ単位がユーザ・データを含むかどうかを判定する。データ単位がユーザ・データを含む場合、プロセッサは、スパース・オブジェクト（sparse object）を診断ファイルに書き込む。
【００１４】
本発明の特色と考えられる新規な特徴が、添付の特許請求の範囲において説明される。しかし、本発明自体は、本発明の好ましい使用方法、さらなる目的、および利点と同様、本発明の例示的な実施形態についての以下の詳細な説明を添付の図面と併せて読みながら参照することによって最も良く理解されよう。
【発明を実施するための最良の形態】
【００１５】
ここで図面を、特に図１を参照すると、本発明の実施形態を実施し得るデータ処理システムのブロック図が示されている。示された例では、データ処理システム１００は、ノース・ブリッジおよびメモリ・コントローラ・ハブ（ＭＣＨ）１０８と、サウス・ブリッジおよび入力／出力（Ｉ／Ｏ）コントローラ・ハブ（ＩＣＨ）１１０とを含むハブ構成を利用する。処理ユニット１０２、メイン・メモリ１０４、およびグラフィックス・プロセッサ１１８は、ノース・ブリッジおよびメモリ・コントローラ・ハブ１０８に接続する。グラフィックス・プロセッサ１１８は、アクセラレーテッド・グラフィックス・ポート（ＡＧＰ）またはグラフィックス・プロセッサ１１８を介して、ノース・ブリッジおよびメモリ・コントローラ・ハブ１０８に接続してもよい。
【００１６】
示された例では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ１１２、オーディオ・アダプタ１１６、キーボードおよびマウス・アダプタ１２０、モデム１２２、読み取り専用メモリ（ＲＯＭ）１２４、ユニバーサル・シリアル・バス（ＵＳＢ）ポートおよびその他の通信ポート１３２、ならびにＰＣＩ／ＰＣＩｅデバイス１３４が、バス１３８を介して、サウス・ブリッジおよびＩ／Ｏコントローラ・ハブ１１０に接続する。ＰＣＩ／ＰＣＩｅデバイスは、例えば、イーサネット・アダプタ、アドイン・カード、およびノートブック・コンピュータ用のＰＣカードを含むことができる。ＰＣＩはカード・バス・コントローラを使用するが、ＰＣＩｅは使用しない。ＲＯＭ１２４は、例えば、フラッシュ・バイナリ入力／出力システム（ＢＩＯＳ：binary input/output system）とすることができる。
【００１７】
ハード・ディスク・ドライブ１２６、およびＣＤ−ＲＯＭドライブ１３０は、バス１４０を介して、サウス・ブリッジおよびＩ／Ｏコントローラ・ハブ１１０に接続する。ハード・ディスク・ドライブ１２６、およびＣＤ−ＲＯＭドライブ１３０は、例えば、統合ドライブ電子（ＩＤＥ）またはシリアル・アドバンスト・テクノロジ・アタッチメント（ＳＡＴＡ）インタフェースを使用することができる。スーパーＩ／Ｏ（ＳＩＯ）デバイス１３６は、サウス・ブリッジおよびＩ／Ｏコントローラ・ハブ１１０に接続されることができる。
【００１８】
オペレーティング・システムは、処理ユニット１０２上で動作し、図１のデータ処理システム１００内の様々なコンポーネントを調整および制御する。オペレーティング・システムは、ＩＢＭ（ＩＢＭはＩＢＭ  Ｃｏｒｐｏｒａｔｉｏｎの商標）コーポレーションから入手可能なアドバンスト・インタラクティブ・エグゼクティブ（ＡＩＸ（Ｒ））などの市販のオペレーティング・システムとすることができる。ＡＩＸは、ＩＢＭ  Ｃｏｒｐｏｒａｔｉｏｎの登録商標である。
【００１９】
本発明の様々な実施形態は、重荷となるユーザ・データを送信する面倒を伴わずに、ファイル・システム不整合の詳細だけを送信することを可能にする。ユーザ・データは、ファイル・システム・データの大部分をなす傾向にあり、したがって、場所確保形式（place-keeping form）で以外は送信されない。ファイル・システム整合性チェック・プログラムは、ファイル・システム内の複数のデータ単位を識別する。識別するための１つの方法は、ファイル・システム整合性チェック・プログラムが、１つのデータ単位から別のデータ単位に移動しながら、ファイル・システムのツリー状構造を識別することである。いくつかの実施形態は、ブロックと同じ大きさのデータ単位を使用することができる。別の実施形態は、例えば、セクタなど、より大きなデータ単位を使用することができる。データ単位がファイル・システム・メタデータまたはメタデータを含む場合、ソフトウェアは、メタデータの単位を、診断ファイル・システムの一部とすることができる診断ファイルに書き込みまたはコピーする。データ単位がユーザ・データを含む場合、ソフトウェアは、スパース・オブジェクトを診断ファイルに書き込みまたはコピーする。その後、診断ファイルをバックアップまたはその他の方法で統合するステップは、スパース・オブジェクトを、元のユーザ・ファイルのコンパクトではあるが完全に空で何も書き込まれていないバージョンとして扱う。スパース・オブジェクトは、ファイルのメタデータ内のヌル・ポインタとすることができる。このポインタは指示対象をポイントしないので、保存された基となるデータがなく、単に空またはすべてが「０」のデータ単位を表すにすぎない。したがって、そのようなスパース・オブジェクトは、ある意味で、ファイル・システムを構成するディスクまたはその他の媒体上のデータ単位内の「０」領域の代わりに用いられる場所確保データとして動作する。したがって、処理システムは、ソース・ファイル・システムと比べて非常に縮小された形式で各スパース・オブジェクトを送信することができる。
【００２０】
図２は、本発明の例示的な一実施形態に従って、顧客システム２０１がどのように専門家システム２０５と対話することができるかを示している。顧客システム２０１は、例えば、図１の処理システム１００を使用して動作することができる。管理者は、ファイル・システムが異常な挙動をしていると断定することができる。それに応じて、管理者は、稠密診断データを含む稠密診断ファイルを生成するために、顧客システム２０１を操作することができる。
【００２１】
専門家システム２０５は、顧客システム２０１から診断ファイル・システムを受信することができる。専門家システム２０５は、診断ファイル・システムにサービスを提供して、サービス済ファイル・システムを形成する。専門家システム２０５は、例えば、図１の処理システム１００を使用して動作することができる。サービス提供は、例えば、診断ファイル・システム上で保守を実行して、サービス済ファイル・システムを形成することを含むことができる。加えて、サービス提供は、診断ファイル・システム上で回復動作を実行することを含むことができる。請求システム２０７は、診断ファイル・システム上の動作を監視することができる。請求システム２０７は、診断ファイル・システムにサービス提供した際に提供されたサービスに対する請求を顧客に行うことができるように、専門家システム２０５上の動作を監視することができる。専門家システム２０５は、顧客システム２０１にサービス済ファイル・システムを返送する。
【００２２】
稠密ファイル・フォーマットは、スパース・ファイルが圧縮されたときに生じる結果である。管理者は、とりわけ、以下で説明されるようにユーザ・データを縮小するファイル整合性チェックを実行するため、コマンド・ライン・エディタでコマンドを入力することができる。プロセッサは、そこに格納されている内容のタイプさえ隠蔽する程度までユーザ・データを縮小することができるので、１つまたは複数の結果のファイルは稠密であり、ファイル・システム・エラーの源泉により直接的に関係するメタデータを有する。したがって、稠密診断データという用語は、本発明の様々な例示的な実施形態から生じる１つまたは複数のコンパクト化されたファイルを示すのに利用される。言い換えると、稠密診断データは、ユーザ・データを除去するかまたはユーザ・データの代わりに場所確保データを使用し、次にその結果の１つまたは複数のファイルを圧縮した後に生成される。
【００２３】
顧客システム２０１は、例えば、インターネット２０３などのネットワークを介して、稠密診断データを送信する。稠密診断データは、専門家システム２０５に到着する。専門家システム２０５は、データ回復専門家の制御下にあることができる。データ回復専門家は、管理者との確立された信用関係を有していないこともある。加えて、インターネット２０３は、安全性の欠しいデータ送信手段として知られている。
【００２４】
図３は、本発明の例示的な一実施形態による、ソース・ファイル・システムから診断ファイルへの変換を仲介するオペレーティング・システムの動作を示している。オペレーティング・システム３０１は、例えば、図１の処理ユニット１０２などのプロセッサ上で動作することができる。ソース・ファイル・システム３０３は、例えば、図１のハード・ディスク・ドライブ１２６などに保存されることができる。管理者は、コマンド・ライン・エディタ３１１を使用して、コマンドを個々にオペレーティング・システム３０１に入力することができる。１つまたは複数のコマンドが、診断ファイル３０５を生成することができる。加えて、ユーティリティ・プログラムが、コマンド・ライン・エディタ３１１の代わりに使用されることができ、その場合、ユーティリティ・プログラムは、オペレーティング・システムにコマンドを書き込む。
【００２５】
図４は、従来のファイル・フォーマットの一例を示している。シーク・コマンドを使用するとき、ファイル・ポインタが、例えば、「０」ブロック４１３などの物理ディスク・アドレスを除外するとしても、ファイル４１１に割り当てられた各ビットは、「０」に設定される。このフォーマットでは、プロセッサは、ファイルのすべての割り当てビットおよびブロックを物理的に書き込み、物理レベルにおいて圧縮は利用されない。
【００２６】
図５は、診断ファイルに関連し得る、スパース・オブジェクトと呼ばれることもある、スパース・ファイル・フォーマットの一例を示している。このフォーマットは、各ビットの論理書き込みを実行するプロセッサを伴うが、実際には、プロセッサは、ファイル・ポインタが指示するデータだけを物理的に保存する。ファイル・ポインタは、次の物理書き込みが生じることになるロケーションである。プロセッサがファイル書き込みの間にギャップが存在することを許可する場合、例えば、ブロック・ポインタ・テーブル４１４などのメタデータ内に表記が作成される。プロセッサは、「０」からなるブロックが論理的に記録されるヌル・ポインタ４１５、４１６、４１７、および４１８を設定することによって、ブロック・ポインタ・テーブル４１４に表記を作成する。言い換えると、各ヌル・ポインタは、さもなければハード・ドライブに物理的に書き込まれていた「０」からなるブロックのための一種の場所確保データとして動作する。「０」からなる大きな領域は後の読み取りにおいて回復され得るので、このフォーマットはスパース（sparse）である。さらに、ファイル・メタデータは、「０」からなる領域をユーザ・データに保存するのではなく、「０」ブロックへの参照が保持される場所である。「０」からなる領域または「０」ブロックは、スパース・オブジェクトによって表され、いくつかのファイル・システムは、例えば、プログラムがオペレーティング・システムに読み取りを要求したときなど、オペレーティング・システムの通常の動作中に、「０」からなる大きな領域をスパース・オブジェクトから読み取ることができる。
【００２７】
稠密ファイル・フォーマットは、スパース・ファイルが圧縮されたときに生じる結果である。プロセッサは、各「０」ブロックを著しく圧縮することができる。いくぶん無秩序な「１」と「０」のシーケンスから構成されるデータも同様に圧縮されるが、おそらくそれほどは圧縮されない。したがって、「０」ブロックは、ファイルのすべてが圧縮形式で物理的に書き込まれるように、いくぶん無秩序なデータと一緒に圧縮される。診断データとして始まった１つまたは複数のファイルは、圧縮が完了すると、稠密診断データになることができる。
【００２８】
図６は、本発明の例示的な一実施形態による、ファイル・システムに関する診断データを取得する最初のステップを示している。管理者は、コマンド・ラインを入力して、各ステップを実行するようオペレーティング・システムに命令することによって、これらのステップを実行するようプロセッサに命令することができる。自動的に次々と実行されるコマンドのスクリプトにすべてのステップを統合することも、等しく適している。オペレーティング・システムは、例えば、図３のオペレーティング・システム３０１とすることができる。プロセッサは、診断ファイル・システムを生成するためのコマンドを受け取る（ステップ５０１）。診断ファイル・システムは、図３の診断ファイル３０５に関連することができる。ＵＮＩＸ（Ｔｈｅ  Ｏｐｅｎ  Ｇｒｏｕｐの商標）ライクなシステムでは、新規に生成されたファイル・システムをオペレーティング・システムでアクセス可能にするには、コマンドが必要なことがある。この例示的な実施形態では、そのコマンドは「mount」である。プロセッサは、診断ファイル・システムをマウントするためのmountコマンドを受け取る（ステップ５０３）。これで、診断ファイル・システムは、データを収集するための準備が整う。プロセッサは、診断ファイルにメタデータを抽出するためのコマンドを受け取る（ステップ５０５）。そのコマンドは、例えば、ファイル・システム整合性チェックfsckとすることができる。診断ファイルは、スパース・オブジェクトを含むことができる。診断ファイルは、診断ファイル・システムの構成要素であることによって、診断ファイル・システムに関連することができる。
【００２９】
fsckは、多くのデータを生成し、それらは、プロセッサが診断ファイル・システムを生成したときに割り当てられた記憶域を埋め尽くす可能性がある。したがって、プロセッサは、抽出されたメタデータが診断ファイル・システムに収まるかどうかを調べるためにテストを行う（ステップ５０７）。収まらないという判定を下した場合、プロセッサは、より大きな診断ファイル・システムを生成するためのコマンドを受け取ることができる（ステップ５０９）。プロセッサは、ステップ５０９の後、診断ファイル・システムのマウントおよびその他のステップを実行することができる。
【００３０】
プロセッサが抽出されたメタデータは診断ファイル・システムに収まるという判定を下した場合、処理は結合子「Ａ」から図７へと続いて行く。
【００３１】
ファイル・システムを生成し、ファイル・システムをマウントする代替方法が存在する。例えば、診断データを記録する目的で、専用ファイル・システムが存在することができ、稠密診断データを専用ファイル・システムに書き込む動作の前に削除されることができる。
【００３２】
データ処理システムが回復を行う１つの方法は、ファイル・システムのデータ構造全体にわたる完全な歩き（walk）または横断（traverse）を実行することである。横断は、その他のステップと同様、どのような不整合でも検出し、訂正することができる。この修復を実行するのに使用される１つのツールが、ファイル整合性チェックまたはfsckコマンドである。その他のファイル整合性チェック・プログラムは、「チェック・ディスク」プログラムとしても知られるマイクロソフトの「chkdsk」を含む。コンピュータ管理者は、ファイル・システムを有するオペレーティング・システムを利用するコンピュータでfsckを使用する。そのようなオペレーティング・システムは、例えば、操作がＵＮＩＸに類似したＡＩＸおよびＬｉｎｕｘ（ＬｉｎｕｘはＬｉｎｕｓ  Ｔｏｒｖａｌｄｓの商標）を含む。Ｌｉｎｕｘは、リーナス・トーバルズの登録商標である。ＵＮＩＸは、オープン・グループの登録商標である。その他のオペレーティング・システムのクラスは、Ｍｉｃｒｏｓｏｆｔ（ＭｉｃｒｏｓｏｆｔはＭｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎの商標）コーポレーションによる様々な世代のＷｉｎｄｏｗｓ（ＷｉｎｄｏｗｓはＭｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎの商標）オペレーティング・システム、およびＡｐｐｌｅ（ＴＭ）コーポレーションによるＭａｃＯＳを含む。ファイル・システムの例は、ＩＢＭの拡張ジャーナル・ファイル・システムまたはＪＦＳ２などのジャーナル・ファイル・システムを含む。
【００３３】
Ｕｎｉｘライクのオペレーティング・システムのファイル・システムは、いくつかの点で冗長データ用に記憶域が割り当てられているかのように振舞う、冗長データを保存するための便利な方法を提供する。その方法は、サイズが少なくとも１ブロックのスパース・オブジェクトを生成することを含む。処理システムが最初にファイルを開くとき、プロセッサは、ファイルの先頭をポイントするファイル・ポインタを生成することができる。ファイル・ポインタは、プロセッサが次にデータを書き込むべき場所を示す場所確保データとして動作し、その場合、プロセッサは、ファイルを線形であるとして扱う。言い換えると、プロセッサは、次に書き込みコマンドを実行するとき、ファイル・ポインタがある場所に書き込みを行う。書き込みコマンドを伴わずにプロセッサがファイル・ポインタを進める場合、ファイル・システムによってファイル用に確保された領域ができるが、ファイルへのブロックの対応する割り当ては行われない。代わりに、ファイル・システム・メタデータは、拡張空ヘッドの存在を数バイトでファイルに保存するが、プロセッサは、どのデータ単位も使用されているとして印付けしない。データ単位は、例えば、ブロックとすることができる。多くのブロックがこの方法で使用されているとして示されれば、数バイトが多くのブロックを表し得るので、実際に使用されるディスク・スペースが大幅に節約される。ファイル・ポインタを前方および反対方向に動かす一般的な方法は、Ｕｎｉｘライクなシステムで普通に利用可能なlseekシステム・コールを使用する。その他のシステムでは、その他のファイル・ポインタ移動コマンドが存在する。
【００３４】
ファイル整合性チェックが探すものの１つは、データ構造における不整合である。ファイル整合性チェック・ソフトウェアは、ファイル・システム用のデータ構造を探査することによって不整合を探す。ファイル・システム用のデータ構造は、ルートとルートから延びる１つまたは複数のブランチとを有するツリーから構成される。例えば、ディレクトリ構造は、ルートから始まり、ルートの下に１つまたは複数のディレクトリを有することができる。同様に、各ファイルは、ブロックに保存されたその構成部分を有し、ブロックも、多数のブランチおよび層を有することができ、その場合、ブロックは、各分岐点におけるノードである。さらなるブロックへのポインタまたは参照を含むブロックは、そのようなポインタをメタデータとして保存する。
【００３５】
ファイル整合性チェック・ソフトウェアは、データ単位からデータ単位へ横断することによってツリーを探査し、各データ単位は、ブロックとすることができる。横断とは、ファイル整合性チェック・ソフトウェアが、ブロックをその下のさらなるブランチの存在について検査し、いくつか存在する場合、ソフトウェアが、今度は各ブランチを検査し、すべてのブランチが検査され尽くすまで、それを続けることを意味する。検査とは、多くのことを意味する。一般に、検査とは、プロセッサがさらなるブランチに沿ってさらなる参照またはポインタを探すことを意味する。
【００３６】
整合性のあるファイル・システムでは、各データ単位は、そのデータ単位への参照を正確に１つだけ有し、これは、プロセッサがデータ単位を１回だけ横断することを意味する。やはり、データ単位は、例えば、ブロックとすることができる。しかし、不整合なファイル・システムでは、ブロックが複数回参照されることがある。ソフトウェアは、横断することによってファイルの単位を識別することができる。例えば、ファイル整合性チェック・ソフトウェアは、第１のファイルを横断し、あるブロックが第１のファイルに割り当てられていることを認識することができる。ソフトウェアは、第２のファイルを横断し、その同じブロックが第２のファイルにも割り当てられていることに認識することができる。これは本当は、ファイル・システムが、事故的に同じブロックを２回割り当てたもので、第１のファイルのデータは第２のファイルのデータによって上書きされる可能性がある。すべてのファイルを横断することによって、ファイル整合性チェックは、多くの問題を発見することができる。
【００３７】
ファイル整合性チェックは、質問／回答形式によるユーザとの対話に応じて、問題を修復することができる。しかし、この機能は、非常に複雑かつ専門的なので、ファイル・システムの管理者は、できるだけ多くのデータを回復するため、専門家からの外部支援を求めることがある。多くの専門家は高い適格性を備えているが、残念ながら、ファイル・システムの管理者と専門家の間に確立されたレベルの信用がないこともある。言い換えると、ファイル・システム上のユーザ・データが危険にさらされることから保護する機構が存在することが必要である。
【００３８】
ソフトウェア開発者は、fsckおよびその他のファイル整合性チェッカにコードを追加することができる。追加のコードは、各ファイルに割り当てられたブロックを横断するときに、追加のステップを実行する。不整合を認識するのに加えて、fsckは、各ファイルのある様相のコピーを書き込むことができる。横断および書き込みの処理は、上記の図６のステップ５０５で実行される。コピーは、プロセッサが診断ファイル・システムを生成したときに割り当てられた記憶域を埋め尽くす可能性がある。
【００３９】
図７は、本発明の例示的な一実施形態による、１つまたは複数のファイル・システムに関する診断データをパッケージ化して送信するステップを示している。図３のオペレーティング・システム３０１などのオペレーティング・システムは、図７のステップを実行することができる。代替として、図７のステップは、ユーティリティ・プログラムによって実施されることができ、その場合、ユーティリティ・プログラムは、コマンドをオペレーティング・システムに書き込む。一般に、図７のステップは、より小さく、ネットワークまたはその他の手段を介し転送するのがより容易なデータ構造を生成する汎用的機能を達成する。最初、オペレーティング・システムは、診断ファイル・システムを単一のファイルにバックアップまたはその他の方法で統合する（ステップ５１１）。その後、オペレーティング・システムは、ファイルを圧縮することができる（ステップ５１３）。オペレーティング・システムが圧縮を行った場合、それは、プロセッサが、繰り返しおよび冗長性を利用してデータを要約し、短縮された要約を保存することを意味する。例えば、４０９６個の「０」からなるブロックを記述するための、４０９６個の「０」をすべて示すのとは別の方法は、単に電子的に４０９６×０を保存することであり、そのほうがはるかに短い。加えて、ヌル・ポインタがすでにメタデータ内に存在していることがあるので、単にヌル・ポインタを保存することが、圧縮として動作する。ヌル・ポインタの大きなシーケンスさえも、圧縮されることができる。例えば、１０００個のヌル・ポインタからなるシーケンスを記述するための、物理的に各ヌル・ポインタを保存するのとは別の方法は、電子的に１０００×ｎｕｌｌを保存することである。その後、オペレーティング・システムは、圧縮されたファイルまたは稠密診断データを送信する（ステップ５１５）。したがって、オペレーティング・システムは、ユーザ・データを稠密診断データに変換する。推定上、多くの小さなファイルを有する１０２４ギガバイトの拡張ジャーナル・ファイル・システム（ＪＦＳ２）ファイル・システムは、約１６０メガバイトの稠密診断データに変換されることができ、これは６０００分の１の圧縮である。
【００４０】
図８は、拡張ファイル整合性チェック・ソフトウェアを使用して診断データを取得する詳細なステップを示している。拡張ファイル整合性チェックは、fsckの変形とすることができる。fsckは、ファイル・システム内の各データ単位を横断する（ステップ６２１）。fsckを実行するプロセッサは、データ単位がファイル・システム・メタデータを含むかどうかを判定することができる（ステップ６２３）。「含む」によって、データ単位が、ファイル・システムを構成するすべてのメタデータの少なくとも一部を含むことが意味される。fsckは、データ単位がファイル・システム・メタデータであるとの判定に応答して、メタデータの単位を書き込む（ステップ６２５）。さもなければ、ステップ６２３および６２５は、ステップ６２７に続く。fsckは、データ単位がユーザ・データを含むかどうかを判定する（ステップ６２７）。fsckは、データ単位がユーザ・データであるとの判定に応答して、スパース・オブジェクトを診断ファイルに書き込む（ステップ６２９）。スパース・オブジェクトの書き込みは、プロセッサがヌル・ポインタをメタデータに書き込むことを含むことができる。ヌル・ポインタは、例えば、図５のブロック・ポインタ・テーブル４１４のヌル４１５とすることができる。fsckは、横断されるさらなるデータ単位が残っているかどうかを判定する（ステップ６３１）。ステップ６２５および６２９の各書き込みは、診断ファイルへのものとすることができ、その場合、診断ファイルは、図３の診断ファイル・システム３０５に関連することができる。スパース・オブジェクトは、ブロックが空かまたは有効でないデータで満たされていることを認識する以外、ディスクへの書き込みがデータを変化させない点で、非スパース・オブジェクトとは異なる。ブロック全体を占有する代わりに、fsckは、メタデータに関連するすべてのスパース・オブジェクトのリストを単に作成するにすぎない。代替として、fsckは、lseekシステム・コールを単に使用して、書き込みのために開かれたファイルのファイル・ポジションを進める。lseekシステム・コールは、Ｕｎｉｘライクのオペレーティング・システムで利用可能なファイル・ハンドリング・システム・コールである。基本的に、lseekコマンドは、現在のファイル末尾を越えてファイル・ポジションを動かすようにオペレーティング・システムに命令する。lseekシステム・コールがブロック全体を越えてファイル・ポジションを進めた場合、オペレーティング・システムは、記憶域の物理ブロックをディスク・ドライブに割り当てることなく、ブロックがスパース・ブロックまたはスパース・オブジェクトであることを記録する。スパース・オブジェクトは、記憶域の仮想ブロックであるが、物理的記憶域の完全なブロックのスペースを占有しない。むしろ、メタデータは、とりわけ、ファイルに関連するそのようなブロックの数を識別する。それにも関わらず、プロセッサは、ファイルによって占有される全スペースがディレクトリの一覧表示中に決定されるとき、そのようなスパース・オブジェクトを計算に追加する。
【００４１】
図９は、本発明の例示的な一実施形態による、ＡＩＸオペレーティング・システムのコマンド・ラインで入力されるコマンドの一例を示している。山括弧<>で括られたテキストは、ユーザ指定の文字列を示す。例えば、<新規ファイル・システム・サイズ>  ７１０は、新規ファイル・システムに割り当てられる５１２バイトのブロックの個数を指定する数とすることができる。
【００４２】
第１のステートメントは、crfsコマンド７０１を使用して、ファイル・システムを生成する。フラグは以下の通りである。
【００４３】
-v jfs2  ７０３は、仮想ファイル・システムのタイプを指定する。
【００４４】
-g rootvg  ７０５は、ファイル・システムを作成すべき既存のボリューム・グループを指定する。ボリューム・グループは、１つまたは複数の物理的ボリュームの集まりである。
【００４５】
-m /newfs  ７０７は、ファイル・システムが利用可能にされるディレクトリであるマウント・ポイントを指定する。
【００４６】
-a size=<新規ファイル・システム・サイズ>  ７０９は、５１２バイトのブロック数でＪＦＳ２のサイズを指定し、その際、指定されたサイズが物理的パーティション・サイズで均等に割り切れない場合、プロセッサは、均等に割り切れる最も近い数に切り上げる。
【００４７】
診断ファイル・システムは、図３の診断ファイル・システム３０５とすることができる。
【００４８】
mount /newfs  ７２１は、ファイル・システムをマウントするようプロセッサに命令する。
【００４９】
次がファイル整合性チェックであり、以下のフラグを含むfsck  ７２２コマンドを使用する。
【００５０】
-n  ７２３は、非対話モードで、すなわち、修復についてユーザに問い合せず、指定されたファイル・システムを変更せずにファイル整合性チェックを実行するようプロセッサに命令する。
【００５１】
-o metacapture=/newfs/out1  ７２５は、メタデータおよびスパース・オブジェクトのコピーをスパース・オブジェクトを有するファイルに書き込むようプロセッサに命令するパラメータを識別し、その場合、ファイルは、/newfs/out1またはユーザ指定のディレクトリに置かれる。
【００５２】
<ファイル・システム・マウント・ポイント>  ７３５は、プロセッサが診断を実行するファイル・システムの識別情報である。
【００５３】
プロセッサは、残りの２つのコマンド・ラインに基づいて統合を行う。backup  ７３９は、fsck  ７２２で生成されたすべてのファイルを単一のファイルに配置するようプロセッサに命令する。すなわち、診断ファイル・システムを単一のファイルに配置する。backup  ７３９は、以下のフラグを含む。
【００５４】
-f <目的ファイル名>  ７４１は、出力を保存する１つまたは複数の装置を識別する。
【００５５】
-0 /newfs  ７４３は、バックアップのためのソース・ファイル・システムを指定する。
【００５６】
compress  ７５１は、スパース・オブジェクトを圧縮トークンで置き換えるステップである。compress  ７５１がとる唯一のパラメータは、稠密診断データが保存されるファイルである<目的ファイル名>である。
【００５７】
統合は、ファイル整合性チェックによって提供された個々のファイルを使い、各ファイルを圧縮することによってもなされ得ることが理解される。その場合、各ファイルが稠密診断データになり、ファイルの集まりに追加される各後続ファイルが、稠密診断データに加わる。
【００５８】
したがって、本発明の態様は、ファイル・システム不整合を修復するために任命された専門家からさえもユーザ・データが保護された方法で、ファイル・システム不整合に関する詳細を取得するためのコンピュータ実施方法、機器、およびコンピュータ使用可能プログラム・コードを提供する。加えて、本発明の態様は、ファイル・システム開発者が、ファイル・システム不整合に寄与するかもしれない開発中のソフトウェアにおいて問題を診断することを可能にする。さらに、スパース・オブジェクトは、スパース・オブジェクトを論理ボリュームに抽出できる、またはスパース・オブジェクトを直接見てファイル・システム問題をデバッグできるサービス・チームに送られることができる。
【００５９】
本発明の実施形態は、完全なハードウェア実施形態、完全なソフトウェア実施形態、またはハードウェア要素とソフトウェア要素の両方を含む実施形態の形を取ることができる。好ましい一実施形態では、本発明は、ファームウェア、常駐ソフトウェア、マイクロコードなどの、ただしこれらに限定されないソフトウェアで実施される。
【００６０】
さらに、本発明は、コンピュータもしくは任意の命令実行システムによってまたはそれらに関連して使用するためのプログラム・コードを提供するコンピュータ使用可能またはコンピュータ可読媒体等から取得可能なコンピュータ・プログラムの形を取ることができる。この説明では、コンピュータ使用可能またはコンピュータ可読媒体等は、命令実行システム、機器、または装置によってまたはそれらに関連して使用するためのプログラムを格納、保存、伝達、伝播、または転送することができる任意の機器とすることができる。
【００６１】
媒体は、電子、磁気、光学、電磁気、赤外線、または半導体システム（または機器もしくは装置）、あるいは伝播媒体とすることができる。コンピュータ可読媒体の例は、半導体またはソリッド・ステート・メモリ、磁気テープ、着脱可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、固定磁気ディスク、および光ディスクを含む。光ディスクの現行例は、コンパクト・ディスク−読み取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）、およびＤＶＤを含む。
【００６２】
プログラム・コードを保存または実行し、あるいはその両方を行うのに適したデータ処理システムは、システム・バスを介してメモリ要素に直接的または間接的に結合される少なくとも１つのプロセッサを含む。メモリ要素は、プログラム・コードを実際に実行するときに利用されるローカル・メモリ、大容量ストレージ、実行中に大容量ストレージからコードを取り出さなければならない回数を減らすためにプログラム・コードの少なくとも一部を一時的に記憶するキャッシュ・メモリを含むことができる。
【００６３】
（キーボード、ディスプレイ、ポインティング・デバイスなどを含むが、これらに限定されない）入力／出力またはＩ／Ｏ装置は、直接的にまたは仲介Ｉ／Ｏコントローラを介してシステムに結合されることができる。
【００６４】
データ処理システムが、その他のデータ処理システムまたは遠隔プリンタもしくは記憶装置に仲介私設または公衆ネットワークを介して結合されることができるように、ネットワーク・アダプタもシステムに結合されることができる。モデム、ケーブル・モデム、およびイーサネット・カードは、現在利用可能なタイプのネットワーク・アダプタのうちのほんの２、３の実例である。
【００６５】
本発明の説明は、例示および説明の目的で提示されたもので、網羅的であること、または本発明を開示された形態に限定することは意図されていない。当業者には、多くの変更および変形が明らかであろう。本発明の例示的な実施形態は、本発明の原理および実際的な応用を最も良く説明し、企図される特定の使用に適した様々な変更を有する様々な実施形態について当業者が本発明を理解できるように選択され、説明された。
【図面の簡単な説明】
【００６６】
【図１】本発明の実施形態が実施され得るデータ処理システムのブロック図である。
【図２】本発明の例示的な一実施形態に従って、顧客システムがどのように専門家システムと対話することができるかを示した図である。
【図３】本発明の例示的な一実施形態による、ソース・ファイル・システムから診断ファイルへの変換を仲介するオペレーティング・システムの動作を示した図である。
【図４】本発明の例示的な一実施形態による、従来のファイル・フォーマットの一例を示した図である。
【図５】本発明の例示的な一実施形態による、スパース・ファイル・フォーマットの一例を示した図である。
【図６】本発明の例示的な一実施形態による、ファイル・システムに関する診断データを取得する最初のステップを示した図である。
【図７】本発明の例示的な一実施形態による、ファイル・システムに関する診断データをパッケージ化して送信するステップを示した図である。
【図８】本発明の例示的な一実施形態による、拡張ファイル整合性チェック・ソフトウェアを使用して診断データを取得する詳細なステップを示した図である。
【図９】本発明の例示的な一実施形態による、ＡＩＸオペレーティング・システムのコマンド・ラインで入力されるコマンドの一例を示した図である。
【符号の説明】
【００６７】
１００  データ処理システム
１０２  処理ユニット
１０４  メイン・メモリ
１０８  ノース・ブリッジおよびメモリ・コントローラ・ハブ（ＭＣＨ）
１１０  サウス・ブリッジおよび入力／出力（Ｉ／Ｏ）コントローラ・ハブ（ＩＣＨ）
１１２  ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ
１１６  オーディオ・アダプタ
１１８  グラフィックス・プロセッサ
１２０  キーボードおよびマウス・アダプタ
１２２  モデム
１２４  読み取り専用メモリ（ＲＯＭ）
１２６  ハード・ディスク・ドライブ
１３０  ＣＤ−ＲＯＭドライブ
１３２  ユニバーサル・シリアル・バス（ＵＳＢ）ポートおよびその他の通信ポート
１３４  ＰＣＩ／ＰＣＩｅデバイス
１３６  スーパーＩ／Ｏ（ＳＩＯ）デバイス
１３８  バス
１４０  バス
２０１  顧客システム
２０３  インターネット
２０５  専門家システム
２０７  請求システム
３０１  オペレーティング・システム
３０３  ソース・ファイル・システム
３０５  診断ファイル
３１１  コマンド・ライン・エディタ
４１１  ファイル
４１３  「０」ブロック
４１４  ブロック・ポインタ・テーブル
４１５  ヌル・ポインタ
４１６  ヌル・ポインタ
４１７  ヌル・ポインタ
４１８  ヌル・ポインタ
【図１】
2007095064.tif 000003
【図２】
2007095064.tif 000004
【図３】
2007095064.tif 000005
【図４】
2007095064.tif 000006
【図５】
2007095064.tif 000007
【図６】
2007095064.tif 000008
【図７】
2007095064.tif 000009
【図８】
2007095064.tif 000010
【図９】
2007095064.tif 000011