JP5877186B2 - 情報処理装置 - Google Patents

Description

本発明は、ファイルを管理する情報処理技術に関する。

ハードディスクなどの記録ディスクに対してファイルの書込と削除を繰り返し行うと、記録ディスク内でのファイルの配置が不連続になり、断片化した空き領域が生じる。断片化が進むと、連続した空き領域が少なくなり、１つのファイルを分割して２つ以上の空き領域に分けて保存する必要が生じる。このようなファイルの分割保存が増えると、オペレーティングシステム（ＯＳ）の処理負荷が増大し、またドライブヘッドの移動量が多くなるため、データの読出／書込速度が低下する。そこで、記録ディスク内のファイルを先頭から再配置して、空き領域の断片化を解消するコンパクションツールと呼ばれるソフトウェアが開発されている。

ファイルシステムにおいて、ファイルの記録場所の情報は管理されており、コンパクションツールの実行によりファイルの記録場所が変更されると、記録場所の管理情報は、新たな記録場所の情報に更新される必要がある。従来のコンパクションツールの実行には時間がかかることが指摘されており、効率的にコンパクションを実行できる技術の開発が望まれている。

上記課題を解決するために、本発明のある態様の情報処理装置は、複数のデータブロックで構成されるファイルのメタデータを保持するメタデータ保持部と、データブロックの記録場所を特定するための情報と、当該データブロックのメタデータを保持するメタデータ保持部を特定するための情報とを対応付けた対応ファイルを保持する対応ファイル保持部と、データブロックの記録場所を変更する変更処理部と、メタデータ保持部に保持されたメタデータを更新する更新処理部と、を備える。更新処理部は、対応ファイルを参照して、変更処理部により記録場所を変更されるデータブロックのメタデータを保持するメタデータ保持部を特定し、メタデータを更新する。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明の情報処理技術によると、コンパクションなどの処理を効率的に行うことが可能となる。

本発明の実施例にかかる情報処理システムを示す図である。 情報処理装置の機能ブロックを示す図である。 ファイルのデータブロックのアドレッシングに使用されるデータ構造を説明するための図である。 補助記憶装置におけるセーブデータ領域の記録状況を模式的に示す図である。 コンパクション用の対応ファイルの一例を示す図である。 情報処理装置のブロック管理機能を実現するための構成を示す図である。

図１は、本発明の実施例にかかる情報処理システム１を示す。
情報処理装置１０は、ユーザが操作する入力装置６と無線または有線で接続し、入力装置６はユーザの操作結果を示す操作情報を情報処理装置１０に出力する。情報処理装置１０は入力装置６から操作情報を受け付けるとＯＳ（システムソフトウェア）やアプリケーションソフトウェアの処理に反映し、出力装置４から処理結果を出力させる。情報処理システム１において情報処理装置１０はゲームソフトウェアを実行するゲーム装置であり、入力装置６はゲームコントローラなど情報処理装置１０に対してユーザの操作情報を供給する機器であってよい。入力装置６は複数のプッシュ式の操作ボタンや、アナログ量を入力できるアナログスティック、回動式ボタンなどの複数の入力部を有して構成される。

補助記憶装置２はＨＤＤ（ハードディスクドライブ）やフラッシュメモリなどの大容量記憶装置であり、ＵＳＢ（Universal Serial Bus）などによって情報処理装置１０と接続する外部記憶装置であってよく、また内蔵型記憶装置であってもよい。出力装置４は画像を出力するディスプレイおよび音声を出力するスピーカを有するテレビであってよく、またコンピュータディスプレイであってもよい。出力装置４は、情報処理装置１０に有線ケーブルで接続されてよく、無線接続されてもよい。

アクセスポイント（以下、「ＡＰ」とよぶ）８は、無線アクセスポイントおよびルータの機能を有し、情報処理装置１０は、無線または有線経由でＡＰ８に接続して、インターネットなどの外部ネットワーク上のサーバと通信可能に接続できる。

図２は、情報処理装置１０の機能ブロック図を示す。情報処理装置１０は、メイン電源ボタン２０、電源ＯＮ用ＬＥＤ２１、スタンバイ用ＬＥＤ２２、システムコントローラ２４、クロック２６、デバイスコントローラ３０、メディアドライブ３２、ＵＳＢモジュール３４、フラッシュメモリ３６、無線通信モジュール３８、有線通信モジュール４０、サブシステム５０およびメインシステム６０を有して構成される。

メインシステム６０は、メインＣＰＵ（Central Processing Unit）、主記憶装置であるメモリおよびメモリコントローラ、ＧＰＵ（Graphics Processing Unit）などを備える。ＧＰＵはゲームプログラムの演算処理に主として利用される。これらの機能はシステムオンチップとして構成されて、１つのチップ上に形成されてよい。メインＣＰＵはＯＳを起動し、ＯＳが提供する環境下において、補助記憶装置２やＲＯＭ媒体４４に記録されたゲームソフトウェアを実行する機能をもつ。

サブシステム５０は、サブＣＰＵ、主記憶装置であるメモリおよびメモリコントローラなどを備え、ＧＰＵを備えない。サブＣＰＵの回路ゲート数は、メインＣＰＵの回路ゲート数よりも少なく、サブＣＰＵの動作消費電力は、メインＣＰＵの動作消費電力よりも少ない。上記したように、サブＣＰＵは、メインＣＰＵがスタンバイ状態にある間に動作するものであり、消費電力を低く抑えるべく、その処理機能を制限されている。なおサブＣＰＵおよびメモリは、別個のチップに形成されてもよい。

メイン電源ボタン２０は、ユーザからの操作入力が行われる入力部であって、情報処理装置１０の筐体の前面に設けられ、情報処理装置１０のメインシステム６０への電源供給をオンまたはオフするために操作される。以下、メイン電源がオン状態にあるとは、メインシステム６０がアクティブ状態にあることを意味し、メイン電源がオフ状態にあるとは、メインシステム６０がスタンバイ状態にあることを意味する。電源ＯＮ用ＬＥＤ２１は、メイン電源ボタン２０がオンされたときに点灯し、スタンバイ用ＬＥＤ２２は、メイン電源ボタン２０がオフされたときに点灯する。

システムコントローラ２４は、ユーザによるメイン電源ボタン２０の押下を検出する。メイン電源がオフ状態にあるときにメイン電源ボタン２０が押下されると、システムコントローラ２４は、その押下操作を「オン指示」として取得し、一方で、メイン電源がオン状態にあるときにメイン電源ボタン２０が押下されると、システムコントローラ２４は、その押下操作を「オフ指示」として取得する。

メインＣＰＵは補助記憶装置２やＲＯＭ媒体４４に記録されているゲームプログラムを実行する機能をもつ一方で、サブＣＰＵはそのような機能をもたない。しかしながらサブＣＰＵは補助記憶装置２にアクセスする機能、ネットワーク上のサーバとの間で情報を送受信する機能を有している。サブＣＰＵは、このような制限された処理機能のみを有して構成されており、したがってメインＣＰＵと比較して小さい消費電力で動作できる。これらのサブＣＰＵの機能は、メインＣＰＵがスタンバイ状態にある際に実行される。

クロック２６はリアルタイムクロックであって、現在の日時情報を生成し、システムコントローラ２４やサブシステム５０およびメインシステム６０に供給する。

デバイスコントローラ３０は、サウスブリッジのようにデバイス間の情報の受け渡しを実行するＬＳＩ（Large-Scale Integrated Circuit）として構成される。図示のように、デバイスコントローラ３０には、システムコントローラ２４、メディアドライブ３２、ＵＳＢモジュール３４、フラッシュメモリ３６、無線通信モジュール３８、有線通信モジュール４０、サブシステム５０およびメインシステム６０などのデバイスが接続される。デバイスコントローラ３０は、それぞれのデバイスの電気特性の違いやデータ転送速度の差を吸収し、データ転送のタイミングを制御する。

メディアドライブ３２は、ゲームなどのアプリケーションソフトウェア、およびライセンス情報を記録したＲＯＭ媒体４４を装着して駆動し、ＲＯＭ媒体４４からプログラムやデータなどを読み出すドライブ装置である。以下では、プログラムおよびデータを特に区別しない場合には、まとめてデータと呼ぶこともあるが、データは、ファイルを構成する要素を表現するものとしても使用する。ＲＯＭ媒体４４は、光ディスクや光磁気ディスク、ブルーレイディスクなどの読出専用の記録メディアである。

ＵＳＢモジュール３４は、外部機器とＵＳＢケーブルで接続するモジュールである。ＵＳＢモジュール３４は補助記憶装置２とＵＳＢケーブルで接続してもよい。フラッシュメモリ３６は、内部ストレージを構成する補助記憶装置である。無線通信モジュール３８は、Bluetooth（登録商標）プロトコルやIEEE802.11プロトコルなどの通信プロトコルで、たとえば入力装置６と無線通信する。なお無線通信モジュール３８は、ＩＴＵ（International Telecommunication Union；国際電気通信連合）によって定められたＩＭＴ−２０００（International Mobile Telecommunication 2000）規格に準拠した第３世代（3rd Generation）デジタル携帯電話方式に対応してもよく、さらには別の世代のデジタル携帯電話方式に対応してもよい。有線通信モジュール４０は、外部機器と有線通信し、たとえばＡＰ８を介して外部ネットワークに接続する。

本実施例の情報処理装置１０は、ＵＮＩＸ（登録商標）で利用されるファイル管理手法を利用して、ファイルを管理する。
ファイルは、１または複数のブロックを割り当てられて構成される。ブロックは、ファイルシステムがデータを転送する基本単位であり、１つのブロックは所定のデータサイズ（たとえば６４ｋバイト）に設定される。たとえば、ゲームのセーブデータファイル（以下、単に「セーブデータ」とも呼ぶ）のサイズは、ゲームによって定められているが、ゲームがセーブデータサイズを３２０ｋバイトと定めていれば、セーブデータに５個のブロックが割り当てられることになり、１２８０ｋバイトと定めていれば、セーブデータに２０個のブロックが割り当てられることになる。各ファイルには、ファイルを構成する１または複数のデータブロックの記録場所を格納するための索引表が設定される。

図３は、ファイルのデータブロックのアドレッシングに使用されるデータ構造を説明するための図である。最初の１段目の索引表はｉｎｄｅｘ ｎｏｄｅ（略して「ｉノード」）と呼ばれ、データブロックのアドレッシング用に合計１５個のエントリを有する。全てのファイルはｉノードとデータブロックから構成され、ｉノードは、ファイルシステムにおいてファイルを識別するためのｉノード番号を付与されている。ｉノードは、属性情報として、ｉノード番号、ファイルの種類、ファイルのバイト長、アクセス権などを有している。

ｉノードのエントリには、データブロックに関するメタデータが記録され、代表的にはデータブロックの記録場所を特定するための情報がメタデータとして記録されている。この情報は、たとえば記録ディスクもしくはパーティションの先頭からの相対位置を指定するブロック番号であってよい。なお、データブロックの記録場所を特定するための情報は、ブロック番号に限らず、たとえばブロック番号を算出するためのブロックサイズやファイルオフセットなどの情報であってもよい。またデータブロックの記録場所を特定するための情報は、直接的に記録場所を特定する記録ディスクのセクタ番号であってもよい。

ファイル名と、そのファイルを管理するｉノードのｉノード番号（ｉノードへのポインタとしての意味をもつ）は、ディレクトリのデータブロックにおいて対応付けて保持されている。したがってゲームプログラムがファイルをファイル名で参照するとき、ＯＳのカーネルは、ディレクトリエントリの情報を参照して、そのファイル名に対応するｉノード番号を取得し、ｉノード番号で特定されるｉノードに含まれるブロック番号を用いて、ファイルにアクセスする。

ｉノードの１２個のエントリは、ファイル内の先頭から１２個までのデータブロックのメタデータを記録するために使用される。したがってファイルが１２個以内のデータブロックで構成されていれば、ｉノードは、ブロック数分のエントリを用いて各データブロックのメタデータを記録できる。

なお、ファイルが１３個以上のブロックで構成されていると、複数段の索引表が必要となる。図３に示す例では、ｉノードの１３番目のエントリには、２段目の索引表（インダイレクトブロック）のブロック番号がメタデータとして記録され、ｉノードの１３番目のエントリが、インダイレクトブロックにリンクして、１段階目の間接参照に利用される。インダイレクトブロックは、２５６個のエントリを有している。インダイレクトブロックのエントリには、２段目のデータブロックの記録場所を特定するための情報、ここではブロック番号がメタデータとして記録されている。

ｉノードの１４番目のエントリには、３段目の索引表（ダブルインダイレクトブロック）をリンクするための２段目の索引表（インダイレクトブロック）のブロック番号がメタデータとして記録されている。インダイレクトブロックのエントリには、ダブルインダイレクトブロックのブロック番号がメタデータとして記録されている。ダブルインダイレクトブロックは、２５６個のエントリを有しており、そのエントリには、３段目のデータブロックのブロック番号が記録されている。このようにｉノードの１４番目のエントリは、２段階目の間接参照に利用される。

ｉノードの１５番目のエントリには、４段目の索引表（トリプルインダイレクトブロック）をリンクするための３段目の索引表（ダブルインダイレクトブロック）をリンクするための２段目の索引表（インダイレクトブロック）のブロック番号がメタデータとして記録されている。インダイレクトブロックのエントリには、ダブルインダイレクトブロックのブロック番号がメタデータとして記録されている。ダブルインダイレクトブロックのエントリには、トリプルインダイレクトブロックのブロック番号がメタデータとして記録されている。トリプルインダイレクトブロックは、２５６個のエントリを有しており、そのエントリには、４段目のデータブロックのブロック番号が記録されている。このようにｉノードの１５番目のエントリは、３段階目の間接参照に利用される。
以下、２段目以降の索引表を、まとめてｉｎｄｉｒｅｃｔ Ｂｌｏｃｋ（インダイレクトブロック）と呼ぶこともある。

したがって、セーブデータに５個のブロックが割り当てられる場合、そのセーブデータファイルは、ｉノードにおける５個のエントリのそれぞれに各データブロックのメタデータを記録することで管理される。また、セーブデータに２０個のブロックが割り当てられる場合、そのセーブデータファイルは、ｉノードにおける１２個のエントリと、インダイレクトブロックにおける８個のエントリに各データブロックのメタデータを記録することで管理される。

上記したように、各ｉノードには、ファイルを一意に識別するためのｉノード番号が付与されているが、各インダイレクトブロックにも、各インダイレクトブロックを一意に識別するためのインダイレクトブロック番号が付与されている。インダイレクトブロックは、付与されたインダイレクトブロック番号を、属性情報として有する。１つのファイルシステムにおいて、ｉノード番号は重複しないように設定され、またインダイレクトブロック番号も重複しないように設定される。したがって、ＯＳはｉノード番号を指定すれば、そのｉノード番号のｉノードを参照でき、またインダイレクトブロック番号を指定すれば、そのインダイレクトブロック番号のインダイレクトブロックを参照することができる。

図４は、補助記憶装置２におけるセーブデータ領域の記録状況を模式的に示す。図４（ａ）は、空き領域が断片化した状態を示し、図４（ｂ）は、コンパクション処理により空き領域の断片化が解消された状態を示す。なお図４（ａ）および図４（ｂ）の横長矩形領域はセーブデータの記録領域を模式的に表現し、横長矩形領域における枠はブロックを表現し、ハッチングが施された枠はデータが記録されている状態を、ハッチングが施されていない枠はデータが記録されていない状態を表現している。

コンパクションツールが、セーブデータ領域のコンパクション処理を実行すると、図４（ｂ）に示すようにデータブロックの記録場所が変更される。既述したように、データブロックの記録場所は、ｉノードまたはインダイレクトブロックによって管理されており、そのためＯＳは、データブロックを移動する際には、当該データブロックのブロック番号を記録したｉノードまたはインダイレクトブロックを探索して、ブロック番号を書き換える必要がある。しかしながら、１つのファイルシステムには複数のファイルが含まれており、特に、ゲームソフトウェアは、場合によっては数万個のファイルを有していることもあるため、移動したデータブロックのメタデータを記録するｉノードまたはインダイレクトブロックの探索には時間がかかるという問題がある。

そこで本実施例では、読出／書込されるファイルに関して、コンパクション用の対応ファイルを用意し、データブロックを別の記録領域に移動する際には、ＯＳがコンパクション用対応ファイルを参照して、メタデータを更新するべきｉノードまたはインダイレクトブロックを速やかに特定できるようにする。

図５は、コンパクション用の対応ファイルの一例を示す。
対応ファイルでは、データブロックのブロック番号と、当該データブロックのメタデータが記録されたエントリを含むｉノードのｉノード番号またはインダイレクトブロックのインダイレクトブロック番号とが対応付けられる。対応ファイルの右項目の“ｉノード番号／インダイレクトブロック番号”には、ｉノード番号またはインダイレクトブロック番号が記述され、記述された番号がｉノード番号であるか、またはインダイレクトブロック番号であるかを特定する情報も記述される。この特定情報は、フラグ値として記述されてよく、たとえばフラグ値１は、番号がｉノード番号であることを示し、フラグ値０は、番号がインダイレクトブロック番号であることを示す。

対応ファイルにおいて、ブロック番号“２１９，６５３”に記録されているデータブロックのメタデータは、ｉノード番号“１０３１１”を属性情報として保持するｉノードに格納されている。また、ブロック番号“２２０，１２３”に記録されているデータブロックのメタデータは、インダイレクトブロック番号“４２６８５”を属性情報として保持するインダイレクトブロックに格納されている。したがって、コンパクション処理において移動元と移動先のブロック番号が決定すれば、ＯＳが、この対応ファイルを利用することで、メタデータを格納するｉノードまたはインダイレクトブロックを特定して、移動元のブロック番号を移動先のブロック番号に更新するとともに、また対応ファイルの移動元のブロック番号を移動先のブロック番号に書き換えることができる。

図６は、情報処理装置１０のブロック管理機能を実現するための構成を示す。情報処理装置１０は、処理部１００および補助記憶装置２を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされたプログラム、ストレージなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

メタデータ保持部１１０は、複数のデータブロックで構成されるファイルのメタデータを保持する。メタデータ保持部１１０は、ｉノードおよび／またはインダイレクトブロックであり、またはｉノードおよび／またはインダイレクトブロックを格納する記録領域である。本実施例のファイルシステムは、ｉノードのリストをファイルシステムの管理情報として有しているが、メタデータ保持部１１０は、ｉノードリストまたはｉノードリストを格納する記録領域であってよい。またメタデータ保持部１１０は、インダイレクトブロックリストまたはインダイレクトブロックリストを格納する記録領域を含んでもよい。

対応ファイル保持部１１２は、図５に示すコンパクション用の対応ファイルを保持する。既述したように対応ファイルは、データブロックの記録場所を特定するための情報と、当該データブロックのメタデータを保持するメタデータ保持部１１０を特定するための情報とを対応付けたものであり、具体的には、データブロックのブロック番号と、当該データブロックを管理するｉノードのｉノード番号またはインダイレクトブロックのインダイレクトブロック番号とを対応付けたものである。

なお対応ファイルは、ファイルシステムを構成する全てのデータブロックに対して用意される必要はない。たとえばゲームのファイルシステムで言えば、プログラムファイルなど、ゲームソフトウェアを構成するデータ群は、書き換え不能な読出専用のデータとして構成されている。そのため、これらのデータ群が連続するブロック番号に記録されるような場合には、コンパクション処理を行う必要性に乏しいため、これらのデータブロックは、対応ファイルに含めなくてもよい。なおゲームソフトウェアをネットワークからダウンロードする場合には、ファイルが分割保存されることも想定されるため、そのような場合には、ゲームソフトウェアを構成するデータブロックも、対応ファイルに含めるようにしてもよい。

データブロック記憶部１１４は、複数のデータブロックを記憶する。既述したように、データブロックのブロック番号は、ｉノードまたはインダイレクトブロックにおいて記述されている。

変更処理部１０２は、データブロックの記録場所を変更する。たとえば変更処理部１０２の機能は、記録領域に記録されたデータブロックを再配置するコンパクション処理を実行するコンパクションツールにより実現されてよい。なおこの機能は、デフラグメンテーションツールにより実現されてもよい。

更新処理部１０４は、メタデータ保持部１１０に保持されたメタデータを更新する機能を有する。この更新機能は、変更処理部１０２によりデータブロックの記録場所が変更されるときに実行される。具体的に更新処理部１０４は、対応ファイル保持部１１２に保持された対応ファイルを参照して、変更処理部１０２により記録場所を変更されるデータブロックのメタデータを保持するメタデータ保持部１１０を特定し、当該メタデータ保持部１１０におけるメタデータを更新する。更新するメタデータは、少なくともデータブロックの記録場所を特定するための情報を含み、具体的に変更処理部１０２は、データブロックの記録位置を示すブロック番号を、変更先のブロック番号に更新する。

たとえば変更処理部１０２が、コンパクション処理を実行して、ブロック番号“２１９，６５３”のデータブロックを、ブロック番号“２１０，０００”に配置したとする。変更処理部１０２は、更新処理部１０４に、データブロックを、ブロック番号“２１９，６５３”からブロック番号“２１０，０００”に移動したことを通知する。

更新処理部１０４は、この通知を受けると、対応ファイルを参照して、ブロック番号“２１９，６５３”の記録領域に格納されていたデータブロックを管理しているのがｉノード番号“１０３１１”をもつｉノードであることを特定する。続いて更新処理部１０４は、ｉノード番号“１０３１１”のｉノードを参照して、ブロック番号“２１９，６５３”を記録するエントリを特定し、そのエントリのブロック番号を“２１０，０００”に更新する。

このように更新処理部１０４は、対応ファイルを利用することで、全てのｉノードを探索することなく、移動されたデータブロックを管理するｉノードを高速に特定できるよう能となる。

メタデータの更新と同時に、更新処理部１０４は、対応ファイルにおけるデータブロックの記録場所を特定するための情報、すなわちブロック番号を更新する。これにより図５に示す上段のレコードは、ブロック番号が“２１９，６５３”から“２１０，０００”に書き換えられる。

更新処理部１０４は、ファイルシステムにおいて新たなファイルが生成され補助記憶装置２に記録されると、データブロックのブロック番号と、当該データブロックを管理するｉノードのｉノード番号との関係を、新たなレコードとして対応ファイルに追加する。また更新処理部１０４は、ファイルが削除されると、該当するレコードを対応ファイルから削除する。これにより更新処理部１０４は、対応ファイルのブロック番号を最新の状態に維持することができ、コンパクション処理がいつ実行されても、ｉノードのメタデータ更新を短時間で済ますことができる。

以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。実施例では、ゲームのセーブデータ領域をコンパクション処理する場合について説明したが、セーブデータに限らず、読出／書込可能なデータの記録領域をコンパクション処理する場合に本発明は適用できる。また、ゲームのデータに限らず、他のアプリケーションのデータの記録場所を変更する場合にも本発明は適用できる。

１…情報処理システム、２…補助記憶装置、１０…情報処理装置、１００…処理部、１０２…変更処理部、１０４…更新処理部、１１０…メタデータ保持部、１１２…対応ファイル保持部、１１４…データブロック記憶部。

Claims (7)

1. 複数のデータブロックで構成されるファイルのメタデータを保持するメタデータ保持部と、
   データブロックの記録場所を特定するための情報と、当該データブロックのメタデータを保持するメタデータ保持部を特定するための情報とを対応付けた対応ファイルを保持する対応ファイル保持部と、
   データブロックの記録場所を変更する変更処理部と、
   メタデータ保持部に保持されたメタデータを更新する更新処理部と、を備え、
   更新処理部は、対応ファイルを参照して、変更処理部により記録場所を変更されるデータブロックのメタデータを保持するメタデータ保持部を特定してメタデータを更新し、対応ファイルにおけるデータブロックの記録場所を特定するための情報を更新する、
   ことを特徴とする情報処理装置。
2. メタデータは、データブロックの記録場所を特定するための情報を含むことを特徴とする請求項１に記載の情報処理装置。
3. データブロックの記録場所を特定するための情報は、ブロック番号であることを特徴とする請求項１または２に記載の情報処理装置。
4. メタデータ保持部は、ｉノードであることを特徴とする請求項１から３のいずれかに記載の情報処理装置。
5. 変更処理部は、記録領域に記録されたデータブロックを再配置するコンパクション処理を実行することを特徴とする請求項１から４のいずれかに記載の情報処理装置。
6. コンピュータに、
   データブロックの記録場所が変更されたときに、データブロックのブロック番号と、データブロックを管理するｉノードのｉノード番号とを対応付けた対応ファイルを参照して、記録場所を変更されたデータブロックを管理するｉノードを特定する機能と、
   特定したｉノードに含まれる当該データブロックのブロック番号を更新する機能と、
   対応ファイルに含まれる当該データブロックのブロック番号を更新する機能と、
   を実現させるためのプログラム。
7. 請求項６に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images