はじめに、ディスク状記録媒体のフォーマット方式について説明する。図1は、ディスク状記録媒体全体のフォーマットを説明する図である。ディスクは、長さが可変長の複数のアロケーションエクステントに分割される。アロケーションエクステントは、長さが固定の複数のブロックから構成される。ブロックは、所定の数の物理セクタから構成される。
図2は、アンカーディスクリプタについて説明する図である。ディスク内に、4つのアンカーディスクリプタが配置される。アンカーディスクリプタには、ボリウム管理用マネージメントインフォメーションエリアの位置が記録されている。ボリウム管理用マネージメントインフォメーションエリアのボリウムストラクチャディスクリプタには、フィジカルボリウムインフォメーション、パーティションインフォメーション、ロジカルボリウムインフォメーション、およびパーティションマップが含まれている。
ボリウムストラクチャディスクリプタには、ユーザエリアとしてのロジカルボリウムが記述されている。図3は、ロジカルボリウムを説明する図である。ロジカルボリウムには、ファイルシステムディスクリプタが、配置されている。ロジカルボリウムの先頭付近、および終了付近には、それぞれ、MIA(Management Information Area)が配置されている。MIAには、ファイルテーブル、アロケーションエクステントテーブル、アロケーションストラテジィテーブル、ディフェクトインフォメーションテーブル、エクステンデッドアトリビュートテーブルが含まれている。アロケーションエクステントの長さは、アロケーションストラテジィテーブルを構成するアロケーションストラテジィレコードに記述される。
ユーザは、ディスクにファイルのデータを記録する前に、そのディスクに記録するデータのアロケーションエクステントの長さを予め設定する。これにより、例えば、AVデータは、より長い長さのアロケーションエクステントのフォーマットで記録し、PCデータは短い長さのアロケーションエクステントのフォーマットで記録することが可能となる。AVデータは連続するデータであることが多いので、アロケーションエクステントの長さを長くした方が、データをより効率的に記録再生することができる。
図4は、アロケーションエクステントの長さの設定の処理を説明するフローチャートである。ステップS11において、後述するドライブ部7は、ユーザからの設定入力に対応して、MIAに含まれるアロケーションストラテジィテーブルに、アロケーションエクステントの設定された長さに対応したアロケーションストラテジィレコードを書き込む。アロケーションストラテジィテーブルには、複数のアロケーションストラテジィレコードを書き込むことができる。図5は、アロケーションエクステントの長さをユーザが設定する画面の例を示す図である。アロケーションエクステントの長さとしては、4MByte以上,64KByte,2kByteなど任意の長さが設定可能であり、かつ、複数の長さの設定が可能である。そのディスクには、予め設定した長さのアロケーションエクステントのフォーマットの中から指定されたものでのみ記録が可能である。
このように、アロケーションエクステントの長さを設定し、ディスクに記録した後、そのディスクにデータを記録する場合の処理は、図6のフローチャートに示すようになる。ステップS21において、ユーザは、これから記録するデータのアロケーションエクステントの長さを選択する。図7は、アロケーションエクステントの長さを選択する画面の例を表している。この長さとしては、そのディスクに予め設定された値だけが表示される。画面のボタンを操作することで、ボタンに対応するアロケーションエクステントの長さが、選択される。AVデータを記録するとき、PCデータを記録するときに較べて、より長いアロケーションエクステントを指定することで、より効率的なデータの記録が可能になる。アロケーションエクステントの長さの指定により、アロケーションストラテジィテーブル内に配置されたアロケーションストラテジィレコードが指定される。指定が完了すると、ステップS22において、ドライブ部7は、入力されたデータをディスクに記録する。データの記録が完了すると、ステップS23において、ドライブ部7は、ディスクにそのファイルのアロケーションエクステントの長さに対応した番号を記録する。後述するファイル管理部6は、アロケーションエクステントの長さに対応した番号を知ることにより、対応するアロケーションストラテジィレコードの内容を利用することができる。
後述する図19のシステムコントロール部5が、AVデータを記録しようとしているのか、PCデータを記録しようとしているのかを判断することができる場合には、前述のステップS21をユーザからの入力なしに行うことも可能である。
以上のように、ディスクにファイルが記録される。
ボリウムの構成について説明する。ディスクエクステント(DescExtent)は、後述のMIA内に記録されたディスクリプタ(descriptor)中の後述するMIB(Management Information Block)にアライメントされた領域を表現するのに用いられる。ディスクエクステントは表1に示す様式で記録する。
オフセットフロムトップオブディスクリプタ(Offset from top of a descriptor:RBP 0)は、ディスクリプタ(記述子)の先頭MIBから領域までのオフセット(MIB数)を指定する。レングス(Length :RBP 2)は領域の大きさ(MIB数)を指定する。
PDLエントリ(Primary Defect List Entry)は、ディフェクトマネージメント(defect management)においてスリッピング(slipping)を行う物理セクタ(physical sector)の物理セクタサイズ(physical sector size)を記録するのに用いる。PDLエントリは表2に示す様式で記録する。
フィジカルセクタナンバオブディフェクトセクタ(Physical Sector Number of Defect Sector :RBP 0)はスリッピングを行う物理セクタの物理セクタ番号を指定する。
SDLエントリ(Secondary Defect List Entry)は、ディフェクトマネージメントにおいてリニアリプレースメント行う物理セクタの物理セクタ番号とその代替として使用する物理セクタの物理セクタ番号を記録するのに用いる。SDLエントリは表3に示す様式で記録する。
表3のフィジカルセクタナンバオブディフェクトセクタはリニアリプレースメントを行う物理セクタの物理セクタ番号を指定する。フィジカルセクタナンバオブスペアセクタ(Physical Sector Number of Spare Sector:RBP 4)はリニアリプレースメントで使用する代替物理セクタの物理セクタ番号を指定する。
アンカーポイント(Anchor points)は、ボリウム構造解析の開始点である。アンカーポイントにはアンカーディスクリプタ(Anchor Descriptor)が記録される。アンカーポイントである物理セクタの物理セクタ番号は規定しない。
ただし、VDRでは、以下のように規定される。すなわちROM(Read Only Memory)ディスク,RAM(Random Access Memory)ディスクの場合はCh, 20h, LPSN(Last Physical Sector Number)-20h, LPSN-Ch(hが最後についた数値は、16進数を表す)をアンカーポイントする。パーシャルROMディスクの場合には、ROM、RAMそれぞれの領域でのCh, 20h, LPSN-20h, LPSN-Chをアンカーポイントとする。この場合、もしRAM領域のアンカーポイントに適切な情報が記録されている場合にはそれを使用し、適切な情報が記録されていなかった場合には、ROM領域の情報を使用する。
アンカーディスクリプタはアンカーポイントである物理セクタにバイト位置0から記録される。アンカーディスクリプタの大きさは物理セクタサイズ以下である。また、ディスクリプタの最終バイトの次のバイトからその物理セクタの最後のバイトまでの領域は、将来の拡張の為に予約されており、全てのバイトに#00を設定する。アンカーディスクリプタには、メイン(Main) MIA領域の定義とリザーブ(Reserve) MIA領域の定義、そしてそれぞれのMIAマップ(Map)の位置情報などが記録される。
ボリウムに関する各種の情報はボリウム管理用マネージメントインフォメーションエリア (MIA)に記録される。信頼性確保のため、等しい内容の情報を持つMIAが物理ボリウム上の2ヶ所に記録され、それぞれメインMIA, リザーブMIAと称する。MIA内の物理セクタはマネージメントインフォメーションブロック(Management Information Block:MIB)と呼ばれ、その物理セクタ番号のMIAの先頭MIBからのオフセットはマネージメントインフォメーションブロック番号(Management Information Block Number :MIB Number)と称する。MIBの指定にはMIB番号が使われる。MIAは、欠陥などにより使用することが出来ないMIB、未使用のMIB、並びにメインMIAのMIAマップ(MIA Map for Main MIA)、リザーブMIAのMIAマップ(MIA Map for Reserve MIA)、ボリウムストラクチャディスクリプタ(Volume Structure Descriptor)、メディアインフォメーションディスクリプタ(Media Information Descriptor)、ドライブインフォメーションディスクリプタ(Drive Information Descriptor)、およびエクステントデータディスクリプタ(Extended Data Descriptor)のデータを記録するのに使われるMIBから構成される。
MIA中のMIBがどの目的で使われているかはMIAマップに記録される。メインMIAとリザーブMIAの開始位置と大きさ、MIA中のMIAマップの位置はアンカーディスクリプタで規定される。上記のデータは、1つのMIB内に記録される場合、または複数のMIBにわたって記録される場合がある。データが複数のMIBに記録される場合、どのMIBをどの順番で連結するかはMIAマップ中のMapエントリ(Map Entries)フィールドに記録される。データがMIBの途中で終わった場合には、データの終わりの次のバイトからそのMIBの最後のバイトまでは、#00を設定する。
つぎに、区分(Partition)について説明する。ボリウムストラクチャディスクリプタ(Volume Structure Descriptor)の中のパーティションインフォメーション(Partition Information)で定義されるデータ記憶領域をパーティション(partition)と称する。一つの物理ボリウムを複数のパーティションに分けることができる。物理ボリウム内でパーティションを特定するための番号をパーティション番号と称する。パーティション番号は0から始まり単調に1ずつ増加する整数である。同一のパーティション内の物理セクタは全て同じ物理セクタサイズである。
パーティションは、ボリウムストラクチャディスクリプタの中にパーティションインフォメーション(Partition Information)の表として定義する。パーティションインフォメーションは、パーティションの先頭の物理セクタの物理セクタ番号とそのパーティションに属する物理セクタの数でパーティションを定義する。物理ボリウム中には必ず一つ以上のパーティションが定義される。パーティション番号は、パーティションインフォメーションがボリウムストラクチャディスクリプタに記録された順序で決定される。1番目のパーティションインフォメーションで定義されるパーティションのパーティション番号は0であり、2番目は1であり、以降1ずつ増え、n番目はn-1である。
つぎに論理ボリウム(Logical volume)について説明する。論理ボリウムとは、ボリウムストラクチャディスクリプタの論理ボリウムインフォメーション(Logical Volume Information)において、パーティションの集まりとして定義されるデータ記憶領域をいう。論理ボリウムの領域は、論理ボリウムインフォメーションのパーティションマップ(Partition Map)の記述順にパーティション領域を連結して構成される。パーティションマップは、物理ボリウムを一意に定めるボリウムアイデンティファイア(Volume Identifier)とその物理ボリウムでのパーティション番号の組で論理ボリウムに属するパーティションを指定する。論理ボリウムは、異なる物理ボリウムに属するパーティションから構成されてもよく、1つのパーティションが複数の論理ボリウムに属していてもよい。
論理ボリウムはパーティションの区切れ目や物理セクタなどに関係なく1つの領域として扱われ、その内容は論理セクタ単位に読み書きされる。論理セクタ番号は0から始まり単調に1ずつ増加する整数である。論理ボリウムの大きさが論理セクタサイズの倍数でない場合、最終物理セクタに生ずる半端な領域は、将来の拡張の為に予約されており使用しない。ボリウムストラクチャディスクリプタは、その物理ボリウムに含まれるパーティションに関する情報の定義や論理ボリウムの定義などが記述される。複数の物理ボリウムにまたがる論理ボリウムを定義する場合、必ずパーティション番号 0のパーティションが定義されている物理ボリウムのボリウムストラクチャディスクリプタに、論理ボリウムインフォメーションが記述される。
なお、信頼性確保の為、パーティション番号 0以外のパーティションが属する物理ボリウムのボリウムストラクチャディスクリプタに論理ボリウムインフォメーションを記述してもよい。ボリウムストラクチャディスクリプタは、MIAに記録される。
つぎにディフェクトマネージメント(Defect management)について、説明する。各パーティション毎に、スリッピングとリニアリプレースメントによるディフェクトマネージメントが可能である。それぞれのパーティションに対しディフェクトマネージメントを行うか否かの指定は、ボリウムストラクチャディスクリプタのパーティションインフォメーションで行う。スリッピングとリニアリプレースメントの為に用いる代替データ領域をスペアエリア(spare area)と呼ぶ。ディフェクトマネージメントを行うパーティションと同一の論理ボリウムに属するパーティション内には、必ず1つの以上のスペアエリアを確保する。また、リニアリプレースメントを行う場合、そのパーティション領域の最後は、スペアエリアとなる。
スリッピングを行う場合、そのパーティション領域の最後に確保されたスペアエリアの先頭部分は、スペアエリアとして使用する。また、リニアリプレースメントを行う場合、代替データ領域は、同一の論理ボリウムに属し、かつ、同一の物理ボリウムに属するパーティションであれば、ディフェクトセクタ(defect sector)のあるパーティション内のスペアエリア以外のスペアエリアを使用しても良い。
スリッピングとリニアリプレースメントに関する情報は、ボリウムストラクチャディスクリプタのディフェクトリストインフォメーション(Defect List Information)に記録される。スリッピングに関する情報は、プライマリディフェクトリスト(Primary Defect List)に、リニアリプレースメントに関する情報はセコンダリディフェクトリスト(Secondary Defect List)に記録される。
メディアに関する情報を記録する領域である、メディアインフォメーションディスクリプタ(Media Information Descriptor)は、ゾーンに関する情報などを記録する。ドライブインフォメーションディスクリプタ(Drive Information Descriptor)は、ドライブ(メディアにデータの記録再生を行う装置)に関する情報を記録する領域である。ここには、固定ドライブの場合に各種情報を記録する。
拡張データディスクリプタ(Extended Data Descriptor)は、物理ボリウムインフォメーション、 パーティションインフォメーション、および論理ボリウムインフォメーションヘッダの中に記録しきれなかった拡張情報を記録する。
つぎに、ボリウムデータストラクチャ(Volume data structures)について説明する。アンカーディスクリプタ(Anchor Descriptor)の大きさは物理セクタサイズ以下で、表4に示す様式で記録される。
シグニチャ(Signature:BP 0) のデータタイプフィールドは、16が設定される。スタートフィジカルセクタナンバオブメインMIA(Start Physical Sector Number of Main MIA:BP 8)は、メインMIAの先頭の物理セクタの物理セクタ番号を指定する。ナンバオブフィジカルセクタインメインMIA(Number of Physical Sectors in Main MIA:BP 12) は、メインMIAの物理セクタの数を指定する。スタートフィジカルセクタナンバオブリザーブMIA(Start Physical Sector Number of Reserve MIA:BP 16) は、リザーブMIAの先頭の物理セクタの物理セクタ番号を指定する。ナンバオブフィジカルセクタインリザーブMIA(Number of Physical Sectors in Reserve MIA :BP 20) はリザーブMIAの物理セクタの数を指定する。ナンバオブMIBsフォアMIAマップインメインMIA(Number of MIBs for MIA Map in Main MIA :BP 24) は、メインMIAのMIAマップの大きさ(MIBの数)を指定する。ナンバオブMIBsフォアMIAマップインリザーブ(MIANumber of MIBs for MIA Map in Reserve MIA:BP 26) は、リザーブMIAのMIAマップの大きさ(MIBの数)を指定する。MIBナンバオブMIAマップフォアメインMIAインメインMIA(MIB Numbers of MIA Map for Main MIA in Main MIA:BP 28) は、メインMIAに対するMIAマップを記録しているメインMIA中のMIBを指定する。MIAマップを構成するMIBのMIB番号は、順に設定される。
MIBナンバオブMIAマップフォアリザーブMIAインメインMIA(MIB Numbers of MIA Map for Reserve MIA in Main MIA :BP 28+2x1) は、リザーブMIAに対するMIAマップを記録しているメインMIA中のMIBを指定する。MIAマップを構成するMIBのMIB番号は、順に設定される。MIBナンバオブMIAマップフォアメインMIAインリザーブMIA(MIB Numbers of MIA Map for Main MIA in Reserve MIA :BP 28+2x1+2x2) は、メインMIAに対するMIAマップを記録しているリザーブMIA中のMIBを指定する。MIAマップを構成するMIBのMIB番号は、順に設定される。MIBナンバオブMIAマップフォアリザーブMIAインリザーブMIA(MIB Numbers of MIA Map for Reserve MIA in Reserve MIA:BP 28+4x1+2x2) は、リザーブMIAに対するMIAマップを記録しているリザーブMIA中のMIBを指定する。MIAマップを構成するMIBのMIB番号は、順に設定される。
MIAマップ(MIA Map)は、MIBの使用状況を示すのに使われる。MIAマップは、各種のデータの記録に使われているMIB、欠陥などにより使用することが出来ないMIB、未使用のMIBの位置を示す。MIAマップは表5に示す様式で記録する。
シグネチャ(Signature:BP 0) のデータタイプフィールドは、2が設定される。ロケーションオブMIAマップ(Location of MIA Map:BP 8) は、MIAマップの先頭MIBのMIB番号を指定する。ロケーションオブボリュームストラクチャディスクリプタ(Location of Volume Structure Descriptor:BP 10) は、ボリウムストラクチャディスクリプタの先頭MIBのMIB番号を指定する。ロケーションオブメディアインフォメーションディスクリプタ(Location of Media Information Descriptor:BP 12) は、メディアインフォメーションディスクリプタの先頭MIBのMIB番号を指定する。ロケーションオブドライブインフォメーションディスクリプタ(Location of Drive Information Descriptor:BP 14) は、ドライブインフォメーションディスクリプタの先頭MIBのMIB番号を指定する。
ロケーションオブエクステンデッドデータディスクリプタ(Location of Extended Data Descriptor:BP 16) は、エクステンデッドデータディスクリプタの先頭MIBのMIB番号を指定する。ナンバオブマップエントリーズ(Number of Map Entries:BP 18) は、BP 20から始まるMap Entryのエントリ数を指定する。この数は、MIA内に存在するMIBの数に等しく、#FFF0以下である。マップエントリーズ(Map Entries:BP 20) は、MIBの使用状況を指定する。1つのMap Entryは、Uint16からなっており、最初のマップエントリは最初のMIB, 2番目のマップエントリは2番目のMIB, ..., n番目のマップエントリはn番目のMIBに対応する。表6は、マップエントリの値を示す表である。
図8は、ボリウムストラクチャディスクリプタ(Volume Structure Descriptor)の構造を示す図である。ここで、@APSは、アライントゥフィジカルセクタ(Align to Physical Sector)を示し、そのデータは、物理セクタにアライメントすることを示す。また、アライメントに際し、直前に記録すべきデータが実際に記録された場所の次のバイトからそのセクタの終りまでの領域は、#00が設定される。
ボリウムストラクチャヘッダ(Volume Structure Descriptor Header)は、表7に従って記録される。
シグネチャ(Signature:BP 0) のデータタイプフィールドは、17が設定される。ディスクリプタサイズ(Descriptor Size:BP 8) は、ボリウムストラクチャディスクリプタの大きさ(MIB数)を指定する。リザーブド(Reserved:BP 10)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。オフセットトゥフィジカルボリュームインフォメーション(Offset to Physical Volume Information:RBP 12) は、物理ボリウムインフォメーションのボリウムストラクチャディスクリプタの先頭バイトからのオフセット(バイト数)を指定し、48を設定する。オフセットトゥパーテーションインフォメーション(Offset to Partition Information:RBP 16)は、パーティションインフォメーションのボリウムストラクチャディスクリプタの先頭バイトからのオフセット(バイト数)を指定し、416を設定する。オフセットスペアエリアインフォメーション(Offset to Spare Area Information:RBP 20) は、スペアエリアインフォメーションのボリウムストラクチャディスクリプタの先頭バイトからのオフセット(バイト数)を指定する。オフセットトゥロジカルボリュームインフォメーション(Offset to Logical Volume Information:RBP 24)は、論理ボリウムインフォメーションのボリウムストラクチャディスクリプタの先頭バイトからのオフセット(バイト数)を指定する。オフセットトゥディフェクトリストインフォメーション(Offset to Defect List Information:RBP 28) は、ディフェクトリストインフォメーションのボリウムストラクチャディスクリプタの先頭バイトからのオフセット(バイト数)を指定する。
物理ボリウムインフォメーション( Physical Volume Information)は表8に従って記録しなければならない。
キャラクタセット(Charactor Set:RBP 0) は、物理ボリウムネームフィールドに記録された物理ボリウムの名前の文字コードを指定する。フィジカルボリュームネームサイズ(Physical Volume Name Size:RBP 2) は、物理ボリウムネームフィールドに記録された物理ボリウムの名前の大きさ(バイト数)を指定する。フィジカルボリュームネーム(Physical Volume Name:RBP 4) は、物理ボリウムの名前を指定する。フィジカルボリュームアイデンティファイア(Physical Volume Identifier:RBP 260) は、物理ボリウムを実用上一意に定める為のバイト列を指定する。クリエーションタイム(Creation Time:RBP 280)は、この物理ボリウムのボリウム構造が初めて定義された日時を指定する。モディティフィケーションタイム(Modification Time:RBP 286)は、この物理ボリウムのボリウム構造が変更された最新の日時を指定する。ナンバオブパーテーション(Number of Partitions:RBP 292)は、この物理ボリウムに含まれるパーティションの数を指定し、パーティションインフォメーションの数と一致する。
ナンバオブスペアエリア(Number of Spare Areas:RBP 294)は、この物理ボリウムに含まれるスペアエリアの数を指定し、スペアエリアインフォメーションの数と一致する。ナンバオブパーテーションウィズディフェクトマネージメント(Number of Partitions with Defect Management:RBP 296)は、この物理ボリウムに含まれるパーティションのうち、ディフェクトマネージメントを行うパーティションの数を指定し、ディフェクトリストの数と一致する。ナンバオブロジカルボリューム(Number of Logical Volumes :RBP 298)は、この物理ボリウムに含まれるパーティションが属する論理ボリウムの数を指定し、論理ボリウムインフォメーションの数と一致する。リザーブ土(Reserved:RBP 300)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。エクステンデッドデータアイデンティファイア(Extended Data Identifier:RBP 302) は、エクステンデッドデータフィールド、エクステンデッドデータエリアに記録されているエクステンデッドデータを特定するためのIDを指定する。エクステンデッドデータ(Extended Data:RBP 304)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
パーティションインフォメーション(Partition Information)は、表9で示す様式で記録しなければならない。
スタートフィジカルセクタナンバ(Start Physical Sector Number:RBP 0) は、パーティションを構成する領域の先頭の物理セクタの物理セクタ番号を指定する。ナンバオブフィジカルセクタズ(Number of Physical Sectors:RBP 4) は、パーティションを構成する領域の物理セクタの数を指定する。ナンバオブユーザブルセクタズ(Number of Usable Sectors:RBP 8) は、パーティションを構成する領域のうち、使用することが出来る物理セクタの総数を指定し、パーティションの全領域からそのパーティション領域に含まれるスペアエリアを除いた領域の物理セクタの数と一致する。フィジカルセクタサイズ(Physical Sector Size:RBP 12) は、パーティションを構成する領域の物理セクタの大きさ(bytes数)を指定する。アクセスタイプ(Access Type:RBP 16)は、このパーティションの記録特性の状態を指定する。表10は、アクセスタイプの内容を示す表である。
ユーゼジインフォメーション(Usage Information:RBP 17)は、このパーティションの利用状態を指定する。表11は、ユーゼジインフォメーションの内容を示す表である。
リザーブド(Reserved:RBP 18)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。ロケーションオブプライマリディフェクトリスト(Location of Primary Defect List:RBP 20)は、このパーティションでスリッピングによるディフェクトマネージメントを行う場合、このフィールドにプライマリディフェクトリストが記録された位置に関する情報を格納し、スリッピングによるディフェクトマネージメントを行なわない場合、全てのバイトに#00を設定する。ロケーションオブセカンダリディフェクトリスト(Location of Secondary Defect List:RBP 24)は、このパーティションでリニアリプレースメントによるディフェクトマネージメントを行う場合、このフィールドにセコンダリディフェクトリストが記録された位置に関する情報を格納し、リニアリプレースメントによるディフェクトマネージメントを行なわない場合、全てのバイトに#00を設定する。リザーブド(Reserved:RBP 28)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。エクステンデッドデータアイデンティファイア(Extended Data Identifier:RBP 30) は、エクステンデッドデータフィールド、エクステンデッドデータエリアに記録されているエクステンデッドデータを特定するためのIDを指定する。エクステンデッドデータ(Extended Data:RBP 32)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
スペアエリアインフォメーション(Spare Area Information)は、表12に示す様式で記録する。
スタートフィジカルセクタナンバ(Start Physical Sector Number:RBP 0)は、スペアエリアの先頭の物理セクタの物理セクタ番号を指定する。ナンバオブフィジカルセクタ(Number of Physical Sector:RBP 4) は、スペアを構成する物理セクタの数を指定する。リザーブド(Reserved:RBP 8)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
論理ボリウムインフォメーションヘッダ(Logical Volume Information Header)は、表13で示す様式で記録される。
キャラクタセット(Charactor Set:RBP 0)は、論理ボリウムネームフィールドに記録された論理ボリウムの名前の文字コードを指定する。ロジカルボリュームネームサイズ(Logical Volume Name Size:RBP 2)は、論理ボリウムネームフィールドに指定された論理ボリウムの名前の大きさ(バイト数)を指定する。ロジカルボリュームネーム(Logical Volume Name:RBP 4)は、論理ボリウムの名前を指定する。ブートインジケータ(Boot Indicator:RBP 260)は、論理ボリウムからの起動に関する情報を指定する。ブートインジケータの内容を表14に示す。ブートインジケータがアクティブであり、かつ、その先頭パーティションがその物理ボリウムにある論理ボリウムは、物理ボリウム中に2つ以上あってはならない。
ファイルシステムインジケータ(File System Indicator:RBP 262)は、この論理ボリウムで使用されているファイルシステムを指定する。ファイルシステムインジケータの内容を表15に示す。
ロジカルセクタサイズ(Logical Sector Size:RBP 264)は、この論理ボリウムの論理セクタの大きさ(バイト数)を指定する。ナンバオブパーテーション(Number of Partitions:RBP 266)は、この論理ボリウムを構成するパーティションの数を指定し、パーティションマップの数と一致する。リザーブド(Reserved:RBP 268)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。ロジカルボリュームコンテンツユース(Logical Volume Contents Use:RBP 272)は、この論理ボリウムで使用されているファイルシステムが自由に使用してもよい領域である。リザーブド(Reserved (RBP 288)は将来の拡張の為に予約され、全てのバイトに#00を設定する。エクステンデッドデータアイデンティファイア(Extended Data Identifier:RBP 302) は、エクステンデッドデータフィールド、エクステンデッドデータエリアに記録されているエクステンデッドデータを特定するためのIDを指定する。エクステンデッドデータ(Extended Data:RBP 304)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
パーティションマップ(Partition Map)は表16に示す様式で記録される。
ボリウムアイデンティファイア(Volume Identifier:RBP 0)は、論理ボリウムを構成するパーティションが属している物理ボリウムの物理ボリウムインフォメーションに記録された物理ボリウム識別子を指定する。パーテーションナンバ(Partition Number:RBP 20)は、論理ボリウムを構成するパーティションのパーティション番号を指定する。リザーブド(Reserved:RBP 22)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
ディフェクトリストインフォメーションヘッダ(Defect List Information Header)は表17に示す様式で記録される。
ナンバオブMIBフォアプライマリディフェクトリスト(Number of MIB for Primary Defect List:RBP 0)は、プライマリディフェクトリストを記録するのに使用しているMIBの数を指定する。ナンバオブMIBフォアセコンダリディフェクトリスト(Number of MIB for Secondary Defect List:RBP 2)は、セコンダリディフェクトリストを記録するのに使用しているMIBの数を指定する。リザーブド(Reserved:RBP 4)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
プライマリディフェクトリスト / セコンダリディフェクトリスト(Primary Defect List/Secondary Defect List)は表18に示す様式で記録される。
シグネチャ(Signature:BP 0)のデータタイプフィールドは、プライマリディフェクトリストの場合、18が設定され、セコンダリディフェクトリストの場合、19が設定される。パーテーションナンバ(Partition Number:BP 8)は、このディフェクトリストを使用しているパーティションのパーティション番号を指定する。ナンバオブエントリーズ(Number of Entries:BP 10)は、ディフェクトリストエントリ(Defect List Entry)のエントリ数を指定する。リザーブド(Reserved:RBP 12)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。ディフェクトリストエントリ(Defect List Entry:RBP 16)は、プライマリディフェクトリストの場合、プライマリディフェクトリストエントリを記録し、セコンダリディフェクトリストの場合、セコンダリディフェクトリストエントリを記録する。ディフェクトリストエントリは、どちらの場合も、それぞれのエントリのフィジカルセクタナンバオブディフェクトセクタ(Physical Sector Number of Defect Sector)フィールドの値の昇順に記録する。
メディアインフォメーションディスクリプタ(Media Information Descriptor)の構造を図9に示す。
メディアインフォメーションディスクリプタヘッダ(Media Information Descriptor Header)は、表19に示す様式で記録される。
シグネチャ(Signature:BP 0)のデータタイプフィールドは、20が設定される。ディスクリプタサイズ(Descriptor Size:BP 8)は、メディアインフォメーションディスクリプタの大きさ(MIB数)を指定する。リザーブド(Reserved:BP 10)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。ナンバオブディスクス(Number of discs:BP 16)は、ディスク数を指定する。ナンバオブサイダーズパーディスク(Number of sides per disc:BP 18)は、ディスクあたりのサイド数を指定する。ナンバオブレイヤパーサイド(Number of layers per side:BP 20) は、サイドあたりのレイヤ数を指定する。ナンバオブゾーンズパーレイヤ(Number of zones per layer:BP 22)は、レイヤあたりのゾーン数を指定する。リザーブド(Reserved:BP 24)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。ナンバオブシリンダーズ(Number of cylinders:BP 32)は、シリンダ数を指定する。ナンバオブヘッズ(Number of heads (tracks per cylinder):BP 34)は、ヘッド数(シリンダあたりのトラック数)を指定する。ナンバオブセクタパートラック(Number of sectors per tracks:BP 36)は、トラックあたりのセクタ数を指定する。リザーブド(Reserved:BP 38)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
ゾーンインフォメーション(Zone Information)は、表20に示す様式で記録される。
スタートフィジカルセクタナンバ(Start Physical Sector Number:RBP 0)は、ゾーンの先頭の物理セクタの物理セクタ番号を指定する。ナンバオブフィジカルセクタ(Number of Physical Sector:RBP 4)は、ゾーンを構成する物理セクタの数を指定する。リザーブド(Reserved:RBP 8)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
ドライブインフォメーションディスクリプタ(Drive Information Descriptor)の構造を図10に示す。
ドライブインフォメーションディスクリプタヘッダ(Drive Information Descriptor Header)は、表21に示す様式で記録される。
シグネチャ(Signature:BP 0)のデータタイプフィールドは、21が設定される。ディスクリプタサイズ(Descriptor Size:BP 8)は、ドライブインフォメーションディスクリプタの大きさ(MIB数)を指定する。ストラテジィタイプ(Strategy Type:BP 10)は、ストラテジィタイプを指定する。リザーブド(Reserved:BP 11)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
エクステンデッドデータディスクリプタ(Extended Data Descriptor)の構造を図11に示す。ここで、@APSは、アライントゥフィジカルセクタ(Align to Physical Sector)を示し、そのデータは物理セクタにアライメントしなければならないことを示す。また、直前のデータの次のバイトからそのセクタの終りまでの領域は、#00が設定される。
エクステンデッドデータディスクリプタヘッダ(Extended Data Descriptor Header)は、表22に示す様式で記録される。
シグネチャ(Signature:BP 0)のデータタイプフィールドは、22が設定される。ディスクリプタサイズ(Descriptor Size:BP 8)は、エクステンデッドデータディスクリプタの大きさ(MIB数)を指定する。リザーブド(Reserved:BP 10)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。ロケーションオブエクステンデットデータフォアフィジカルボリューム(Location of Extended Data for Physical Volume:BP 16)は、この物理ボリウムに関する拡張データが記録されている場所を指定する。ロケーションオブエクステンデッドデータフォアパーテーション(Location of Extended Data for Partitions:BP 20)は、各パーティションに関する拡張データが記録されている場所を指定する。ロケーションオブエクステンデッドデータフォアロジカルボリューム(Location of Extended Data for Logical Volume:BP 20+4Np)は、各論理ボリウムに関する拡張データが記録されている場所を指定する。
つぎに、メディア交換のレベル(Levels of medium interchange)について述べる。メディア交換のレベル1は、以下の制限を設ける。すなわち、論理ボリウムは、同一の物理ボリウムに属するパーティションから構成される。同一の物理ボリウムに複数のパーティションが定義される場合、パーティションの領域は、重なってはならない。論理ボリウムを構成するパーティションの物理セクタは、全て同じ物理セクタサイズを有する。論理セクタサイズは、物理セクタサイズの倍数であり、または、物理セクタサイズは、論理セクタサイズの倍数である。パーティションの大きさは、論理セクタサイズまたは物理セクタサイズの大きいほうの値の倍数である。ディフェクトマネージメントを行うパーティションは、必ず1つ以上のスペアエリアを確保する。リニアリプレースメントによるディフェクトマネージメントは、そのパーティション内に確保されたスペアエリアを代替データ領域として使用する。
メディア交換のレベル1は、制限がない。
つぎに、ボリウムストラクチャの例(Example of volume structure)について説明する。表23は、VDRの場合のFAT, ISO9660(with Joliet), ISO/IEC13346, KIFSのハイブリッドディスクのボリウム構造の例を示す表である。表23の◆は再配置不可能な位置固定情報であることを示す。
次に論理ボリウム上に構成されるAVファイルシステム(AV File System)について説明する。論理セクタ番号(Logical Sector Number)は、論理セクタを識別するためにつけられた番号である。論理ボリウム(Logical Volume)は、連続で昇順の0から始まる論理セクタ番号を持つ等しい大きさの論理セクタから構成された集合である。
ファイルシステム管理用マネージメントインフォメーションエリア( Management Information Area (MIA))は、AVファイルシステムの各種の制御情報を格納する論理ボリウム上の連続した複数の論理セクタからなる領域である。マネージメントインフォメーションブロック(Management Information Block (MIB))は、MIA内の論理セクタである。 マネージメントインフォメーションブロック番号(Management Information Block Number (MIB番号))は、マネージメントインフォメーションブロックの論理セクタ番号 NumberからそのMIAの先頭マネージメントインフォメーションブロックの論理セクタ番号を引いた値を有する。
つぎに、AVファイルシステムの全体について説明する。後述するAVファイルシステムディスクリプタ(AV File System Descriptor)は、1個の論理セクタ内に記録され、論理ボリウム上のメインMIAとリザーブMIAの位置、大きさ、そして、メインMIAとリザーブMIA上のMIAマップの位置を指定する。AVファイルシステムディスクリプタの位置は、前述の論理ボリウムインフォメーションヘッダのロジカルボリュームコンテンツユース(Logical Volume Contens Use:BP 284)フィールドに表24に示すように設定される。
メインAVファイルシステムディスクリプタロケーション(Main AV File System Descriptor Location:RBP 0)は、AVファイルシステムディスクリプタの論理セクタ番号を指定する。リザーブAVファイルシステムディスクリプタロケーション(Reserve AV File System Descriptor Location:RBP 4)は、メインAVファイルシステムディスクリプタロケーションで指定されたのとは別の場所にあるAVファイルシステムディスクリプタの論理セクタ番号を指定する。もし、論理ボリウム上にAVファイルシステムディスクリプタが1個しか存在しない場合、リザーブAVファイルシステムディスクリプタロケーションには、#FFFFFFFFがセットされる。リザーブド(Reserved:RBP 8)は、拡張のために予約されており、#00が設定される。
AVファイルシステムの各種の管理情報は、ファイルシステム管理用マネージメントインフォメーションエリア (Management Information Area:MIA)に記録される。信頼性確保の為、等しい内容の管理情報を持つMIAは、論理ボリウム上の2箇所に記録され、それぞれ、メインMIA,リザーブMIAと称する。メインMIAとリザーブMIAの位置、大きさ、MIA中のMIAマップの位置は、AVファイルシステムディスクリプタで規定される。MIA内の論理セクタは、マネージメントインフォメーションブロック (MIB)と称され、その論理セクタ番号のMIAの先頭MIBからのオフセットはマネージメントインフォメーションブロック番号 (MIB番号)と称される。
MIBの指定は、MIB番号が使用される。MIAは、欠陥などにより使用することの出来ないMIB、未使用のMIB、そしてデータ構造体である、MIAマップ(MIA Map)、ファイルテーブル(File Table)、アロケーションエクステントテーブル(Allocation Extents Table、アロケーションストラテジィテーブル(Allocation Strategy Table)、ディフェクトインフォメーションテーブル(Defect Information Table (Optional))、およびエクステンデッドアトリビュートテーブル(Extended Attribute Table (Optional))を格納するのに使われるMIBから構成される。MIA中のMIBがどの目的で使われているかはMIAマップに記録される。各種のデータ構造体は、ひとつのMIB内、または複数のMIBに格納される。データ構造体が複数のMIBに記録される場合、どのMIBをどの順番で連結するかが、MIAマップ中のMap エントリフィールドに記録される。データ構造体がMIBの途中で終わった場合、データの終わりの次のバイトからそのMIBの最後のバイトまでは、#00が格納される。
AVファイルシステムにおいて、ファイルやディレクトリは、後述するファイルテーブルによって管理される。ファイルテーブルの構造は、ファイルテーブルヘッダ中のパラメータであるファイルテーブルストラクチャタイプ(File Table Structure Type)によって決定される。ファイルテーブルストラクチャタイプ0において、ファイルテーブルは、ファイルテーブルヘッダと1個以上のファイルレコードから構成される。ファイルレコードは、固定長のデータ領域で、ファイルレコードを識別するためのフィールド、ファイルレコードの種類を表すフィールド、作成、および修正日時を表すフィールド、データの位置と大きさを表すフィールド、属性を表すフィールド、ペアレントリンク(Parent Link)と称される親ファイルレコードを指すフィールド、ネクストリンク(Next Link)と称される
兄弟ファイルレコードを指すフィールド、チャイルドリンク(Child Link)と称される子ファイルレコードを指すフィールド、並びにエクステンデッドアトリビュートレコードチェィン(Extended Attribute Record Chain)を指すフィールドから構成される。ファイルレコードは、ファイルレコード番号と称される番号が付され、ペアレントリンク、ネクストリンク、チャイルドリンクは、このファイルレコード番号を使って指定される。
ファイルテーブルストラクチャタイプ0では、ファイルテーブルの最初のファイルレコードがルートとなる図12に示されるような木構造が構築される。図中の円は、一つのファイルレコードを表しており、ルートのファイルレコードはルートファイルレコード(Root File Record)と称される。参照すべきデータを持たないファイルレコードは、ディレクトリと称され、データを持つファイルレコードはファイルと称される。ディレクトリばかりでなく、ファイルも子ファイルレコードを有することが出来る。この階層構造は、図13に示されるようにチャイルドリンク(Child Link)、ネクストリンク(Next Link)、ペアレントリンク(Parent Link)を設定する事により実現される。
ネックストリンクで構成されるファイルレコードのリストは、ファイルレコードチェインと呼ばれ、このリスト中には同じファイルIDで、かつ同じファイルタイプを有するレコードが2つ以上あってはならない。サブファイルは、ファイルの一種で、親ファイルレコードの参照するデータの一部分をあたかも別のファイルであるかのように示す。アトリビュート(Attribute)フィールドのデータロケーションタイプ(Data Location Type)に10が設定されたファイルレコードは、サブファイルを表す。
AVファイルシステムではアロケーションエクステント(Allocation Extent)という論理ボリウム上の連続した領域を単位としたデータの管理が実行される。アロケーションエクステントは、論理セクタの任意のバイトオフセットから始まりその論理セクタ内の任意のバイトオフセットで終了するか、あるいは引き続く0個以上の論理セクタを含み、それに続く論理セクタの任意のバイトオフセットで終了する。アロケーションエクステントtの開始点、終了点、属性等はアロケーションエクステントテーブル中のアロケーションエクステントレコードに記録される。
アロケーションエクステントテーブルには論理ボリウム上のすべてのアロケーションエクステントに対応するアロケーションエクステントレコードが、登録される。アロケーションエクステントレコードは、次のアロケーションエクステントレコードを指し示すフィールドを有し、このフィールドを使って複数のアロケーションエクステントレコードから成るリストが作成できる。このリストは、アロケーションエクステントレコードチェインと称される。通常、ファイルデータは、アロケーションエクステントレコードチェインに対応するアロケーションエクステントの順序つき集合として扱われる。
アロケーションエクステントテーブルの中の使用されていないアロケーションエクステントレコード(アロケーションエクステントレコードステータスが00のレコード)から作られたリストは、フリーアロケーションエクステントレコードチェインと称され、アロケーションエクステントテーブルから簡単にたどる事ができる。また対応するアロケーションエクステント中に欠陥(ディフェクト)セクタを含み再利用に問題があると判定されるアロケーションエクステントレコード (アロケーションエクステントレコードステータスに10を有するレコード)を集めて作成したリストをディフェクティブアロケーションエクステントレコードチェインと称し、このリストもアロケーションエクステントテーブルから簡単にたどる事ができる。
アロケーションエクステントを論理ボリウムのどの位置に置くかはアロケーションストラテジィ(Allocation Strategy)によって決定される。アロケーションストラテジィテーブルは、複数のアロケーションストラテジィを登録し、ファイル毎に異なるアロケーションストラテジィを使用して、アロケーションエクステントを論理ボリウム上に配置する事ができる。各アロケーションストラテジィが管理する領域の範囲、またはアロケーションストラテジィが使用するパラメータは、アロケーションストラテジィテーブルの中のアロケーションストラテジィレコードに記録される。ファイルテーブルストラクチャタイプ0において、アロケーションストラテジィは、ファイルレコードごとに決定され、ファイルレコードのデータロケーションフィールドに記録される。このデータロケーションフィールドは、アロケーションエクステントの操作の際に参照され、対応するアロケーションストラテジィが呼び出される。
アロケーションストラテジィタイプ0(Allocation Strategy Type 0)およびアロケーションストラテジィタイプ1(Allocation Strategy Type 1)の2つのアロケーションストラテジィタイプが、定義されている。アロケーションストラテジィタイプ0は、インデックスデータなどの比較的小さなサイズのファイルを非連続的に取り扱う場合に適した方式であり、アロケーションストラテジィタイプ1はMPEG等の連続的にデータの読み書きを行うのに適した方式である。
ディフェクトインフォメーションテーブル(Defect Information Table)は、論理ボリウム内の欠陥セクタの論理セクタ番号を記録したテーブルであり、欠陥セクタの管理に使用できる。
エクステンデッドアトリビュートテーブル(Extended Attribute Table)は、ファイルあるいはディレクトリの拡張属性をMIA中に保持するために使用できる。エクステンデッドアトリビュートテーブルは、エクステンデッドアトリビュートテーブルヘッダ、および1個以上のエクステンデッドアトリビュートテーブルレコードから構成される。エクステンデッドアトリビュートレコードは、リンクのためのフィールドを有する固定長のレコードで、複数のエクステンデッドアトリビュートレコードをリストとしたエクステンデッドアトリビュートレコードチェインを作成できる。
AVファイルシステムが使用するデータ構造の先頭は、シグネチャ(Signature)が設定される。シグネチャは表25に示すように記録される。
アイデンティフィケーション(Identification:RBP 0)は、文字列"AVFS"がISO/IEC 646に従って設定される。バージョン(Version:RBP 4)は、バージョン番号を指定し、1が設定される。データタイプ(Data type:RBP 5)は、データ構造体の種類を指定する。データ構造体の種類により、表26に示される値が設定される。
リザーブド(Reserved:RBP 6)は、拡張のために予約され、#00が設定される。シグネチャは、クラッシュリカバリのときデータ構造体を識別する為に使われる。
AVファイルシステムディスクリプタ(AV File System Descriptor)は、表27に示すように記録される。
シグネチャのデータタイプフィールドは、1が設定される。ロケーションオブメインMIA(Location of Main MIA:BP 8)は、メインMIAの開始論理セクタ番号を指定する。ロケーションオブリザーブMIA(Location of Reserve MIA:BP 12)は、リザーブMIAの開始論理セクタ番号を指定する。レングスオブメインMIA(Length of Main MIA:BP 16)は、メインMIAのサイズを論理セクタ数で指定する。レングスオブリザーブMIA(Length of Reserve MIA:BP 18)は、リザーブMIAのサイズを論理セクタ数で指定する。クリエーションタイム(Creation Time:BP 20)は、AVファイルシステムディスクリプタを作成した日時を格納する。モディティフィケーションタイム(Modification Time:BP 24)は、AVファイルシステムディスクリプタを更新した日時を指定する。ナンバオブMIAマップセクタインメインMIA(Number of MIA Map Sectors in Main MIA:BP 28)は、メインMIAマップセクターズ(Main MIA Map Sectors:BP 32)に記述されたMIB番号の数を指定する。
ナンバオブMIAマップセクターズインリザーブMIA(Number of MIA Map Sectors in Reserve MIA:BP 30)は、リザーブMIAマップセクターズ(Reserve MIA Map Sectors:BP 32 +2x1)に記述されたMIB番号の数を指定する。MIAマップセクタインメインMIA(MIA Map Sectors in Main MIA:BP 32)は、メインMIA中のMIAマップを構成するMIBを指定し、MIAマップを構成するMIBのMIB番号が順に設定される。MIAマップセクターズインリザーブMIA(MIA Map Sectors in Reserve MIA:BP 32 + 2x1)は、リザーブMIA中のMIAマップを構成するMIBを指定し、MIAマップを構成するMIBのMIB番号が順に設定される。
MIAマップ(MIA Map)は、MIA内のMIBの使用状況を示すのに使用される。MIAマップは、MIA内の各種のデータ構造体、欠陥などにより使用することの出来ないMIB、未使用MIBの位置を示す。MIAマップは、表28に示すように記録される。
シグネチャ(Signature:BP 0)のデータタイプフィールドは、2が設定される。ロケーションオブMIAマップ(Location of MIA Map:BP 8)は、このMIA内にあるMIAマップの先頭MIBのMIB番号を指定する。ロケーションオブアロケーションストラテジィテーブル(Location of Allocation Strategy Table:BP 10)は、このMIA内にあるアロケーションストラテジィテーブルの先頭MIBのMIB番号を指定する。ロケーションファイルテーブル(Location of File Table:BP 12)は、このMIA内にあるファイルテーブルの先頭MIBのMIB番号を指定する。
ロケーションオブアロケーションエクステンステーブル(Location of Allocation Extents Table:BP 14)は、このMIA内にあるアロケーションエクステントテーブルの先頭MIBのMIB番号を指定する。ロケーションオブディフェクトリストテーブル(Location of Defect List Table:BP 16)は、このMIA内にあるディフェクトリストテーブルの先頭MIBのMIB番号を指定する。もしこのMIA内にディフェクトリストテーブルが存在しない場合、#FFFFがセットされる。ロケーションオブエクステンデッドアトリビュートディスクリプタ(Location of Extended Attribute Descriptor:BP 18)は、このMIA内にあるエクステンデッドアトリビュートディスクリプタの先頭MIBのMIB番号を指定する。もしこのMIA内にエクステンデッドアトリビュートディスクリプタが存在しない場合、#FFFFがセットされる。リザーブド(Reserved:BP 20)は、拡張のために予約されており、#00が設定される。
ナンバオブマップエントリーズ(Number of Map Entries:BP 22)は、(BP 24)からはじまるマップエントリのエントリ数を指定する。この数は、MIAに存在するMIBの数に等しく、#FFF0以下である。マップエントリーズ(Map Entries:BP 24)は、このMIA内のMIBの使用状況を指定する。1つのマップエントリは、Uint16からなり、最初のマップエントリはMIAの最初のMIB, 2番目のマップエントリは2番目のMIB...に対応する。
マップエントリの値は、表29に示す意味を有する。
もしデータ構造体が論理セクタサイズに等しいかあるいは小さく、1つのMIB内に格納される場合、そのMIBに対応するマップエントリに#FFFFが、セットされる。データ構造体が複数のMIBにわたって記録される場合、最後以外のMIBに対応するマップエントリには次のMIBのMIB番号が、最後のMIBに対応するマップエントリには#FFFFがセットされる。マップエントリの値が#FFF1であるMIBは、そのブロックが未使用である事を示し、データ構造体が新しいMIBを必要とする場合に使用する事が出来る。マップエントリの値が#FFF0であるMIBは、その使用に問題がある(欠陥セクタなど)ことを表す。
ファイルテーブル(File Table)は図14に示すようにファイルテーブルヘッダとファイルテーブルデータから構成される。ファイルテーブルデータの構造はファイルテーブルヘッダのFile Table Structure Typeフィールドによって決まる。
ファイルテーブルヘッダ(File Table Header)は、表30に示すように記録される。
シグネチャ(Signature:BP 0)のデータタイプフィールドは、3が設定される。レングスオブファイルテーブルデータ(Length of File Table Data:BP 8)は、ファイルテーブルデータの長さをバイト数で指定する。ファイルテーブルストラクチャタイプ(File Table Structure Type:BP 12)は、ファイルテーブルデータの構造を規定する。ファイルテーブルストラクチャタイプディペンデントインフォメーション(File Table Structure Type dependent information:BP 14)は、ファイルテーブルストラクチャタイプ毎に決められた情報が設定される。
ファイルテーブルストラクチャタイプ(File Table Structure Type )が0の場合、ファイルテーブルは図15に示すようにファイルテーブルヘッダと1個以上のファイルレコードから構成される。ファイルレコードは、0から始まる連続、昇順の番号が付され、この番号は、ファイルレコード番号と称される。ファイルレコードのリストは次のレコードのファイルレコード番号をネクストリンク(Next Link)フィールドに設定する事により作られ、このリストはファイルレコードチェインと称される。ファイルテーブル内の使用されてないすべてのファイルレコードは、フリーファイルレコードチェインと称されるファイルレコードチェインを作成する。
ファイルテーブルストラクチャタイプが0の場合、ファイルテーブルヘッダ(File Table Header)は表31に示すように記録されなければならない。
シグネチャ(Signature:BP 0)のデータタイプフィールドは、3が設定される。レングスオブファイルテーブルデータ(Length of File Table Data:BP 8)は、ファイルレコードの長さにナンバオブファイルレコーズ(Number of File Records:BP 14)をかけた数が設定される。ファイルテーブルストラクチャタイプ(File Table Structure Type:BP 12)は、0が設定される。ナンバオブファイルレコードズ(Number of File Records:BP 14)は、ファイルテーブルを構成するファイルレコード数を指定する。ファイルレコード数は、1以上#FFF0以下の値をとる。ファーストフリーファイルレコーズ(First Free File Records:BP 14)は、フリーファイルレコードチェインの最初の要素を指し、ファイルテーブル内にフリーなファイルレコードが存在しない場合、#FFFFが設定される。リザーブド(Reserved:BP 18)は、拡張のために予約されており、#00が設定される。
ファイルレコード(File Record)は、表32に示すように記録されなければならない。
ファイルID(File ID:RBP 0)は、ファイルレコードチェイン中の同じファイルタイプを持つファイルレコードを識別するための番号を指定する。ファイルタイプ(File Type:RBP 2)は、このファイルレコードの種類を指示するための番号を指定する。アトリビュート(Attribute:RBP 4)は、このファイルレコードまたはこのファイルレコードの参照するデータの属性を指定する。クリエーションタイム(Creation Time:RBP 8)は、このファイルレコードの作成日時を指定する。モディフィケーションタイム(Modification Time:RBP 12)は、このファイルレコードまたはファイルレコードの参照するデータの変更日時を指定する。データレングス(Data Length:RBP 16)は、データロケーション(Data Location:RBP 24)の参照するデータの長さをバイトで指定し、参照するデータがない場合には0をセットする。データロケーション(Data Location:RBP 24)は、このファイルレコードの参照するデータの位置を指定する。フィールドの解釈は、アトリビュート(Attribute:RBP 4)のデータロケーションタイプ(Data Location Type:Bit 1-2)の内容によって変化する。チャイルドリンク(Child Link:RBP 32)は、チャイルドファイルレコードのファイルレコード番号を指定し、そのようなファイルレコードが存在しない場合、#FFFFが設定される。ネクストリンク(Next Link:RBP 34)は、ファイルレコードチェインを構成する次のファイルレコードのファイルレコード番号を指定し、このファイルレコードがファイルレコードチェインの最後の要素の場合、#FFFFが設定される。
ペアレントリンク(Parent Link:RBP 36)は、ペアレントファイルレコードのファイルレコード番号を指定し、このファイルレコードがルートファイルレコードである場合、自分自身のファイルレコード番号すなわち0が設定される。エクステンデッドアトリビュートレコードナンバ(Extended Attribute Record Number:RBP 38)は、このファイルレコードの使うエクステンデッドアトリビュートレコードチェインの先頭のエクステンデッドアトリビュートレコード番号を指定し、エクステンデッドアトリビュートレコードを参照しない場合、#FFFFが設定される。
アトリビュート( Attribute)フィールドは、表33に示すように記録される。
バリッド(Valid:Bit 0)は、このファイルレコードが有効なレコードであるかどうかを表し、0の場合、このファイルレコードが使われていないことを表し、ファイルレコードは、フリーファイルレコードチェイン中にある。バリッドが、1の場合、このファイルレコードが使用されていることを表し、ルートファイルレコードからチャイルドリンク, ネックストリンクを経て到達する事ができる。データロケーションタイプ(Data Location Type:Bit 0-1)は、データロケーション(Data Location:RBP 24)のフォーマットを指定する。データロケーションタイプが00の場合、データロケーションは参照するものがない事を示す(ファイルレコードがディレクトリの場合は、この値をセットする)。データロケーションタイプが01の場合、データロケーションは、アロケーションエクステントレコードチェインの先頭のアロケーションエクステントレコード番号とアロケーションストラテジィ番号を表34に示すフォーマットで表される。データロケーションタイプが10の場合、ファイルレコードはサブファイルであることを表し、データロケーションは、ペアレントファイルレコードのデータロケーションが表すデータの先頭からのオフセットがUint64で表される。11のデータロケーションタイプは、拡張のために予約されている。
プロテクテッド(Protected:Bit 3)は、このファイルレコードがプロテクトされていることを表す。ソーテッド(Sorted:Bit 4)は、このファイルレコードの属するファイルレコードチェインがファイルタイプの若い順にソートされ、さらに同じファイルタイプの中ではファイルIDの若い順にソートされている事を表す。リザーブド(Reserved:Bit 5-31)は、拡張のために予約されている。
アロケーションエクステントテーブル(Structure of the Allocation Extents Table)は、図16に示すようにアロケーションエクステントテーブルヘッダとアロケーションエクステントレコードから構成される。アロケーションエクステントレコードには0から始まる連続、昇順の番号が付される。この番号は、アロケーションエクステントレコード番号と称される。次のレコードのアロケーションエクステントレコード番号をネクストアロケーションエクステントレコードフィールドに設定する事により、アロケーションエクステントレコードのリストはつくられる。このリストはアロケーションエクステントレコードチェインと称される。
アロケーションエクステントテーブルヘッダ(Allocation Extents Table Header)は、表35に示すように記録される。
シグネチャ(Signature:BP 0)のデータタイプフィールドは、4が設定される。ナンバオブアロケーションエクステントレコーズ(Number of Allocation Extent Records (BP 8)はアロケーションエクステントテーブル中のアロケーションエクステントレコードの数を指定する。ファーストフリーアロケーションエクステントレコード(First Free Allocation Extent Record:BP 12)は、フリーアロケーションエクステントレコードチェインの最初の要素を指す。
アロケーションエクステントテーブル内にフリーなアロケーションエクステントレコードが存在しない場合、#FFFFFFFFがこのフィールドに設定される。ファーストディフェクティブアロケーションエクステントレコード(First Defective Allocation Extent Record:BP 16)は、ディフェクティブアロケーションエクステントレコードチェインの最初の要素を指す。アロケーションエクステントテーブル内にディフェクティブアロケーションエクステントレコードが存在しない場合、#FFFFFFFFが、このフィールドに設定される。リザーブド(Reserved:BP 20)は、拡張のために予約され、#00が設定される。
アロケーションエクステントレコード(Allocation Extent Record)は、アロケーションエクステントの開始位置、終了位置、属性、アロケーションエクステントレコードチェインを構成する次のアロケーションエクステントレコードの位置を表す。アロケーションエクステントレコードは、表36に示すように記録される。
スタートロジカルセクタナンバ(Start Logical Sector Number:RBP 0)は、アロケーションエクステントの開始バイトを含む論理セクタを指定し、論理セクタ番号が設定される。アロケーションストラテジィナンバ(Allocation Strategy Number:RBP 4)は、このアロケーションエクステントレコードがどのアロケーションストラテジィに従って配置されているかを指示する。リザーブド(Reserved:RBP 5)は、拡張のために予約され、#00が設定される。スタートオフセット(Start Offset:RBP 6)は、アロケーションエクステントの開始バイトを含む論理セクタの先頭バイトから開始バイトまでのバイトオフセットを指定し、開始位置がその論理セクタの先頭バイトに等しければ0がセットされる。
エンドロジカルセクタナンバ(End Logical Sector Number:RBP 8)は、アロケーションエクステントの最終バイトを含む論理セクタの論理セクタ番号を指定する。リザーブド(Reserved:RBP 12)は、拡張のために予約され、#00が設定される。エンドオフセット(End Offset:RBP 14)は、アロケーションエクステントの終了バイトを含む論理セクタの先頭バイトから終了バイトまでのオフセットを指定し、終了バイトがその論理セクタの先頭バイトに等しいならば0がセットされる。アトリビュート(Attribute:RBP 16)の表す値は、表37に示す意味を有する。
アロケーションエクステントレコードステータス (Bit 0-1)が01の場合、このアロケーションエクステントレコードは、有効なアロケーションエクステントを指し、正常に読み出しができる。このビットが11の場合、このアロケーションエクステントレコードは有効なアロケーションエクステントを指しており、かつ欠陥セクタの存在などにより、正常に読み出しを出来ない可能性のある事を表す。このビットが00の場合、このアロケーションエクステントレコードは現在使用されておらず、新しいアロケーションエクステントを配置する際に使用出来る事を表す。このビットが10の場合、このアロケーションエクステントレコードの指すアロケーションエクステントは、どこからも参照されていないが、欠陥セクタを含んでいるために新しいアロケーションエクステントを配置する為に使用するのは適当でない事を表す。リザーブド(Reserved:Bit 2-31)は、拡張のために予約されており、0が設定される。
ネクストアロケーションエクステントレコード(Next Allocation Extent Record:RBP 20)は、アロケーションエクステントレコードチェインを構成する次のアロケーションエクステントレコード番号を指定する。アロケーションエクステントレコードがアロケーションエクステントレコードチェインの最後の要素である場合、#FFFFFFFFがセットされる。レングスオブザアロケーションエクステント(Length of the Allocation Extent:RBP 24)は、このアロケーションエクステントレコードが指示するアロケーションエクステントの長さをバイト数で指示する。スタートロジカルセクタナンバ(Start Logical Sector Number:RBP 0)、スタートオフセット(Start Offset:RBP 6)、エンドロジカルセクタナンバ(End Logical Sector Number:RBP 8)、およびエンドオフセット(End Offset:RBP 14)から計算で求められるバイト数とこのフィールドにセットされたバイト数は等しい。
アロケーションストラテジィテーブルはAVファイルシステムがこの論理ボリウムでデータを配置するのに使用しているすべてのアロケーションストラテジィを指定する。アロケーションストラテジィテーブルは図17に示すようにアロケーションストラテジィテーブルヘッダとアロケーションストラテジィレコードから構成される。
アロケーションストラテジィテーブルヘッダ(Allocation Strategy Table Header)は、表38に示すように記録される。
シグネチャ(Signature:BP 0)のデータタイプフィールドは、5が設定される。ナンバオブアロケーションストラテジィレコード(Number of Allocation Strategy Record:BP 8)は、アロケーションストラテジィ テーブル中のアロケーションストラテジィレコードの数を指定する。リザーブド(Reserved:RBP 10)は、拡張のために予約され、#00が設定される。
アロケーションストラテジィレコードは、アロケーションストラテジィを指定するのに使用される。アロケーションストラテジィレコードは、表39に示すように記録される。
レングスオブアロケーションストラテジィレコード(Length of Allocation Strategy Record:RBP 0)は、このアロケーションストラテジィレコードの長さをバイト数で指定し、その長さは8の倍数である。アロケーションストラテジィタイプ(Allocation Strategy Type:RBP 2)は、このアロケーションストラテジィレコードの種類を指定する。アロケーションストラテジィナンバ(Allocation Strategy Number:RBP 4)は、このアロケーションストラテジィレコードがアロケーションストラテジィテーブル中の何番目のレコードであるかを指定し、このレコードが最初のレコードならば0がセットされる。リザーブド(Reserved:RBP 5)は、拡張のために予約されており、#00が設定されなければならない。アロケーションストラテジィタイプディペンデントデータ(Allocation Strategy Type Dependent Data:RBP 8)は、アロケーションストラテジィタイプ毎に決まった内容がセットされる。
アロケーションストラテジィタイプ0においては、次の条件を満足する。第1に、アロケーションエクステントは、アロケーションストラテジィレコードのスタートロジカルセクタナンバ(Start Logical Sector Number:RBP 8)およびエンドロジカルセクタナンバ(End Logical Sector Number:RBP 12)で指定された領域内に配置されなければならない。第2に、論理セクタの一部が、あるアロケーションエクステントに割り当てられている場合、その論理セクタのどのバイトも別のアロケーションエクステントに属さない。第3に、アロケーションエクステントの先頭と論理セクタの先頭は一致する。アロケーションストラテジィタイプ 0のアロケーションストラテジィレコードは、表40に示すように記録される。
レングスオブアロケーションストラテジィレコード(Length of Allocation Strategy Record:RBP 0)は、16が設定される。アロケーションストラテジィタイプ(Allocation Strategy Type:RBP 2)は、0が設定される。アロケーションストラテジィナンバ(Allocation Strategy Number:RBP 4)は、このアロケーションストラテジィレコードがアロケーションストラテジィテーブル中の何番目のレコードであるかを指定し、このレコードが最初のレコードならば0がセットされる。リザーブド(Reserved:RBP 5)は、拡張のために予約され、#00が設定される。スタートロジカルセクタナンバ(Start Logical Sector Number:RBP 8)は、アロケーションエクステントを配置する領域の先頭論理セクタ番号を指定する。エンドロジカルセクタナンバ(End Logical Sector Number:RBP 12)は、アロケーションエクステントを配置する領域の最後の論理セクタ番号を指定する。
アロケーションストラテジィタイプ1のアロケーションストラテジィレコードは、表41に示すように記録される。
レングスオブアロケーションストラテジィレコード(Length of Allocation Strategy Record:RBP 0)は、このアロケーションストラテジィレコードの長さ、16 + 16x1が設定される。アロケーションストラテジィタイプ(Allocation Strategy Type:RBP 2)は、1が設定される。アロケーションストラテジィナンバ(Allocation Strategy Number:RBP 4)は、このアロケーションストラテジィレコードがアロケーションストラテジィテーブル中の何番目のレコードであるかを指定し、このレコードが最初のレコードならば0がセットされる。リザーブド(Reserved:RBP 5)は、拡張のために予約され、#00が設定される。ナンバオブゾーン(Number of Zones:RBP 8)は、アロケーションストラテジィレコード中のゾーンインフォメーションレコードの数を指定する。リザーブド(Reserved:RBP 10)は、拡張のために予約され、#00が設定される。ゾーンインフォメーションレコーズ(Zone Information Records:BP 16)は、ナンバオブゾーン(Number of Zones:RBP 8)で指定された数のゾーンインフォメーションレコードが設定される。ゾーンインフォメーションレコードは、表42に示すように記録される。
スタートロジカルセクタナンバ(Start Logical Sector Number:RBP 0)は、このゾーンの開始論理セクタ番号を指定する。エンドロジカルセクタナンバ(End Logical Sector Number:RBP 4)は、このゾーンの最終論理セクタ番号を指定する。レングスオブアロケーションユニット(Length of Allocation Unit:RBP 8)は、このゾーン内に配置を行う際のアロケーションユニットを指定する。リザーブド(Reserved:RBP 12)は、拡張のために予約され、#00が設定される。
ディフェクトインフォメーションテーブル(Defect Information Table)は論理ボリウム中の欠陥セクタの論理セクタ番号を記録する。ディフェクトインフォメーションテーブルは、表43に示すように記録される。
シグネチャ(Signature:BP 0)のデータタイプフィールドは、6が設定される。ナンバオブディフェクトセクタズ(Number of Defect Sectors:BP 8)は、(BP 16)からはじまるディフェクトセクタアドレスのエントリ数を指定する。リザーブド(Reserved:BP 12)は、拡張のために予約され、#00が設定される。ディフェクトセクタアドレス(Defect Sector Addresses:BP 16)は、この論理ボリウム中で検出されたディフェクトセクタの論理セクタ番号を指定し、1つのエントリはUint32からり、ここに記録される値は昇順にソートされている。
エクステンデッドアトリビュートテーブル(Extended Attribute Table)は、図18に示すようにエクステンデッドアトリビュートテーブルヘッダとエクステンデッドアトリビュートレコードから構成される。エクステンデッドアトリビュートテーブル中のエクステンデッドアトリビュートレコードは、0から始まる連続、昇順の番号が付され、この番号は、エクステンデッドアトリビュートレコード番号と称される。エクステンデッドアトリビュートレコードのリストは、ネクストエクステンデッドアトリビュートレコードフィールドに次のレコードを設定する事により作成され、このリストは、エクステンデッドアトリビュートレコードチェインと称される。エクステンデッドアトリビュートテーブル内の使用されてないエクステンデッドアトリビュートレコードは、フリーエクステンデッドアトリビュートレコードチェインと呼ばれるリストを作成する。
エクステンデッドアトリビュートテーブルヘッダ(Extended Attribute Table Header)は、表44に示すように記録される。
シグネチャ(Signature:BP 0)のデータタイプフィールドは、7が設定される。ナンバオブエクステンデッドアトリビュートレコード(Number of Extended Attribute Record:BP 8)は、エクステンデッドアトリビュートテーブル中のエクステンデッドアトリビュートレコードの数を指定し、#FFF0以下である。ファーストフリーエクステンデッドアトリビュートレコード(First Free Extended Attribute Record:BP 10)は、フリーエクステンデッドアトリビュートレコードチェインの最初の要素を指し、エクステンデッドアトリビュートテーブル内にフリーのエクステンデッドアトリビュートレコードが存在しない場合、#FFFFが設定される。リザーブド(Reserved:RBP 12)は、拡張のために予約され、#00が設定される。
エクステンデッドアトリビュートレコード(Extended Attribute Record)は、表45に示すように記録される。
ネクストエクステンデッドアトリビュートレコード(Next Extended Attribute Record:RBP 0)は、エクステンデッドアトリビュートレコードチェインを構成する次のエクステンデッドアトリビュートレコード番号を指定し、このエクステンデッドアトリビュートレコードが最後のエクステンデッドアトリビュートレコードである場合、#FFFFがセットされる。
既存のファイルシステムの多くはメディアの欠陥セクタ処理をファイルシステムの下に位置するレイヤ(例えばドライブ内部の交替処理)で行う事を前提に設計されている。これらのファイルシステムでは欠陥セクタがどこにあるのかが分からず、欠陥がない部分ではドライブの生の転送速度でデータにアクセスできるが、交替処理が行われている部分ではそれよりもはるかに低い転送速度でしかアクセスが出来ない。
従来のコンピュータ用途では平均アクセス時間の向上が要求される事はあっても個々のアクセス時間の見積もりが要求される事はなかったため上記のような構成でも問題はなかった。しかし、オーディオ, ビデオ用途ではデータを一定時間内に一定量供給できなければ音声や映像を正しく記録再生する事ができないため、ファイルシステムがデータアクセスにかかる時間の見積もりを行える事が必要となってきた。
そこで本ファイルシステムでは欠陥セクタ処理を下のレイヤで行わなくても良いという前提を導入し、ファイルシステムがデータのアクセスにかかる時間を正確に見積もる事が出来るようにした。これに伴い、本ファイルシステムでは従来のファイルシステムにはなかった欠陥セクタ処理の為のフィールドやフラグが用意され、これを使って欠陥セクタの処理が行う事が出来る。ここでは本ファイルシステムに用意された機能を使って欠陥セクタ処理を行う方法の一例を解説する。
一般に欠陥セクタが検出されるのは次のいずれかである。第1に、書き込み中にエラーが発生し欠陥セクタが検出される。第2に、書き込みは正常終了したが、書き込み直後にその部分を読み出した際にエラーが検出される。第3に、書き込み、および書き込み直後の読み出しは正常終了したが、時間を経て読み出しを行った時にエラーが検出される。
第1および第2の場合は、書き込み直後に読み出しを行い、正しく書き込めた事を確認する(Write and Verify)操作を行うことにより書き込み時に検出、対応できる。
第3の場合は、光ディスクにおけるごみ、傷による障害などで発生するケースである。このケースについては完全な対応策は存在しないが、多重書きを行う事により、データロスの可能性を著しく下げる事が出来る。本ファイルシステムは、主にこのWrite and Verifyと多重書きの2つの手法を使って欠陥セクタの処理を行う。
ボリウム構造は、ボリウムストラクチャディスクリプタ(Volume Structure Descriptor)、メディアインフォメーションディスクリプタ(Media Information Descriptor)、ドライブインフォメーションディスクリプタ(Drive Information Descriptor)、およびエクステンデッドデータディスクリプタ(Extended Data Descriptor)により定義される。これらの情報に対する欠陥セクタへの対応は、以下のように行う。
ボリウムストラクチャディスクリプタ、メディアインフォメーションディスクリプタ、ドライブインフォメーションディスクリプタ、およびエクステンデッドデータディスクリプタは、MIAにより管理される。MIAは、記録の際に必ずwrite and verifyを行うことで確実に非欠陥セクタに記録することが可能である。また、MIAは、記録後に生じた欠陥を考慮し、MIAを2個所に重複記録し、MIA内の使用状況を管理するMIAマップについても2個所に重複記録する。
さらに、ボリウム管理システムによって定義される論理ボリウムでは、これを構成するパーティション毎にスリッピング、 リニアリプレースメントによるディフェクトマネージメントが行える。
AVファイルシステムの、欠陥セクタへの対応は以下のように行う。AVファイルシステムは、AVファイルシステムディスクリプタに書き込みを行うとき、Write and Verifyを実行し、正しく書き込めた事を確認し、書き込みに失敗した場合、別の場所にAVファイルシステムディスクリプタを書き、ロジカルボリウムコンテンツユースフィールドの内容を書き換える。また、AVファイルシステムディスクリプタを、2箇所に書くことにより信頼性を向上させる。
AVファイルシステムは、MIA内のセクタの書き込みを行うとき、Write and Verifyを実行し、正しく書き込めた事を確認し、書き込みに失敗した場合、MIAマップのエントリフィールドに#FFF0を書き込み、別のMIA内のセクタに対して同じシーケンスを実行する。また、AVファイルシステムは、MIA自体を論理ボリウム上の2箇所に書くことにより信頼性を向上させる。
AVファイルシステムが動作中に検出した欠陥セクタは、ディフェクトインフォメーションテーブルに登録され、次回からそのセクタは、使用しないようにする事が出来る。
アロケーションエクステントに記録されるデータは、転送速度の要求からWrite and Verify(ライトアンドベリファイ)オペレーションが行えなず、Write(ライト)オペレーションのみを実行するときがある。いずれの場合も欠陥セクタを検出した場合、AVファイルシステムは、その部分を独立したアロケーションエクステントとして、そのアロケーションエクステントレコードのアロケーションエクステントレコードステータスに10が設定され、そのアロケーションエクステントを、ディフェクティブアロケーションエクステントレコードチェインに入れる。読み出し時にアロケーションエクステント中に欠陥セクタを検出した場合、AVファイルシステムは、アロケーションエクステントレコードステータスに11をセットする。このアロケーションエクステントの解放が行われるとき、欠陥セクタが調べられ、その欠陥セクタの部分は、アロケーションエクステントレコードステータスが10のアロケーションエクステントとして、ディフェクティブアロケーションエクステントレコードチェインに登録される。
図19は、本発明の記録再生装置1の一実施の形態の構成を示すブロック図である。記録再生装置1は、光ディスク8が装着され、光ディスク8に外部から供給されたビデオ信号およびオーディオ信号並びにPC(Personal Computer)データを記録するか、または、光ディスク8に記録されている信号を読み取り、外部に出力する。
ユーザ入出力部2は、キーパネル11およびLCD(Liquid Crystal Display)12を有する。キーパネル11は、ユーザの操作に応じた信号を発生し、システムコントロール部5に供給するようになされている。LCD12は、システムコントロール部5から供給された信号に基づき、記録再生装置1の状態または記録再生装置1に装着された光ディスク8に関する情報等を表示する。
AV入出力部3は、エンコーダ/デコーダ13および14並びにマルチプレクサ/デマルチプレクサ15を有し、システムコントロール部5から供給された信号に基づき、エンコーダ/デコーダ13および14並びにマルチプレクサ/デマルチプレクサ15を制御する。また、AV入出力部3は、システムコントロール部5にエンコーダ/デコーダ13および14並びにマルチプレクサ/デマルチプレクサ15の状態を示す信号を供給する。
エンコーダ/デコーダ13は、記録時において、外部から供給されたビデオ信号を圧縮(エンコード)して、ビデオ信号に対応する所定の方式のビデオデータをマルチプレクサ/デマルチプレクサ15に出力し、再生時において、マルチプレクサ/デマルチプレクサ15から供給された所定の方式のビデオデータを伸張(デコード)して外部に出力する。エンコーダ/デコーダ14は、記録時において、外部から供給されたオーディオ信号を圧縮(エンコード)して、オーディオ信号に対応する所定の方式のオーディオデータをマルチプレクサ/デマルチプレクサ15に出力し、再生時において、マルチプレクサ/デマルチプレクサ15から供給された所定の方式のオーディオデータをを伸張(デコード)して外部に出力する。
マルチプレクサ/デマルチプレクサ15は、記録時において、エンコーダ/デコーダ13および14から供給された所定の方式のビデオデータおよびオーディオデータを多重化し、ドライブ部7に出力するようになされている。また、再生時において、ドライブ部7から供給された多重化されたビデオデータおよびオーディオデータを分離し、ビデオデータをエンコーダ/デコーダ13に、オーディオデータをエンコーダ/デコーダ14に出力するようになされている。
PCデータ入出力部4は、インターフェース16を有し、システムコントロール部5から供給された信号に基づき、インターフェース16を制御し、システムコントロール部5にインターフェース16の状態を示す信号を出力する。インターフェース16は、外部のパーソナルコンピュータ(図示せず)等から供給された所定の形式のPCデータを入力し、ドライブ部7が読み取り可能なデータに変更し、ドライブ部7に出力する。インターフェース16は、また、ドライブ部7から供給されたデータを所定の形式で、外部のパーソナルコンピュータ等に出力するようになされている。
システムコントロール部5は、ユーザ入出力部2、AV入出力部3、PCデータ入出力部4、およびファイル管理部6それぞれの状態に基づき、ユーザ入出力部2、AV入出力部3、PCデータ入出力部4、およびファイル管理部6を制御するようになされている。
ファイル管理部6は、システムコントロール部5からの信号に基づき、ドライブ部7を制御し、ドライブ部7の状態に応じた信号をシステムコントロール部5に供給するようになされている。
ドライブ部7は、バッファ17、ECC回路18、変調/復調回路19、およびピックアップ20を有し、ファイル管理部6からの信号に基づき、バッファ17、ECC回路18、変調/復調回路19、およびピックアップ20を動作させ、光ディスク8に信号を記録し、または光ディスク8から信号を読み出すようになされている。
バッファ17は、AV入出力部3またはPCデータ入出力部4から供給されたデータを一時的に記憶し、データが途切れないように、ECC(Error Correction Code)回路18にデータを出力し、また、ECC回路18から供給されたデータを一時的に記憶し、データが途切れないように、AV入出力部3またはPCデータ入出力部4に供給するようになされている。
ECC回路18は、バッファ17から供給されたデータにECCを付加して、変調/復調回路19に出力し、また、変調/復調回路19から供給されたデータを、ECCを基に誤り訂正した後、バッファ17に出力するようになされている。
変調/復調回路19は、ECC回路18から供給されたデータを所定の方式に変調してピックアップ20に出力し、ピックアップ20から供給されたデータを所定の方式に基づいて復調し、ECC回路18に出力するようになされている。
ピックアップ20は、変調/復調回路19から供給されたデータに基づき、記録再生装置1に装着された光ディスク8にデータを記録し、または光ディスク8に記録されたデータを読み取り、変調/復調回路19に出力するようになされている。
図20は、再生のときの、バッファ17に記録されているデータの量とバッファ17に書き込まれるデータの速度の関係を示す図である。バッファ17から出力されるデータの読み出し速度Routは、エンコーダ/デコーダ13および14が信号の出力を途切れさせないようにするため、所定の値以上の一定値となるように制御される。バッファ17に供給されるデータのデータ書き込み速度は、光ディスク8の所定のファイルが記録されているセクタを読み取っているとき、図20(B)に示すように、一定の値Rinになる。一方、データ書き込み速度は、ピックアップ20が光ディスク8のトラックの間を移動しているとき、または所定のセクタがピックアップ20の読み取り可能な位置に来るまで光ディスク8の回転を待っているとき(図20(B)の時間Tsの間)、0になる。
このため、バッファ17へのデータ書き込み速度が0になるとき、バッファ17に記録されているデータの量は、読み出し速度Routで読み出しされるだけとなるため、図20(A)に示されるように、急激に減少する。バッファ17の記憶可能なデータ量は、所定の期間、データ書き込みが無くとも、データの読み出しが途切れないように、Rin、およびデータの読み出し速度により決定される。
図21は、光ディスク8に記録されているファイルの構成を説明する図である。ブロックは、ディスク全体を等しい大きさに分割したもので、ブロック内が物理的に連続で、かつ、ブロック内ではRinの速度でデータの転送が実行される。ファイルのデータは、1または複数のブロックに記録される。従って、ブロックは、ファイルの一部または全部のデータが記録されているブロック、またはファイルのデータが記録されていないブロックにわかれる。ブロックに記録されているファイルのデータ量がブロックの大きさより小さいとき、そのファイルの直前のブロックは、その全てにデータが記録されている。
図22は、ファイルの構成とバッファ17に記憶されたデータの量を示す図である。図22(A)は、ブロックに記録されているファイルを説明する図である。ブロック31は、その全てにファイルのデータが記録されている。ブロック31に連続するブロック32は、その一部にファイルのデータが記録されている。ブロック33は、その全てにファイルのデータが記録されている。ブロック33に連続するブロック34は、その一部にファイルのデータが記録されている。
図22(B)は、図22(A)に示されたブロックを読み出すときのバッファ17への書き込み速度を表す図である。ブロック31を読み出すとき、バッファ17への書き込み速度は、ブロック31が物理的に連続しているため、Rinの一定速度となる。同様に、ブロック32を読み出すとき、ブロック33を読み出すとき、およびブロック34を読み出すとき、バッファ17への書き込み速度は、Rinの一定速度となる。
ブロック31の読み出しを終了し、つぎにブロック32の読み出しを行うとき、ブロック31とブロック32が物理的に連続しているとは限らないため、連続していなければ、ピックアップ20は、光ディスク8のトラックの間を移動するか、または所定のセクタがピックアップ20の読み取り可能な位置に来るまで光ディスク8の回転を待つ。このため、バッファ17への書き込み速度が0になる期間Ts1が存在する。同様に、ブロック32の読み出しを終了し、つぎにブロック33の読み出しを行うとき、バッファ17への書き込み速度が0になる期間Ts2が存在し、ブロック33の読み出しを終了し、つぎにブロック34の読み出しを行うとき、バッファ17への書き込み速度が0になる期間Ts3が存在する。
図22(C)は、バッファ17からのデータ読み出し速度を示す図である。データ読み出し速度は、常に一定の値Routである。図22(D)は、バッファ17に記憶されているデータの量を示す図である。図20(A)に示される場合と同様に、バッファ17のデータ量は、書き込み速度Rinと読み出し速度Routの差に対応する速度で増加し、バッファ17へのデータ書き込み速度が0になるとき、バッファ17に記録されているデータの量は、読み出しだけとなるので、急激に減少する。特に、その一部だけにファイルのデータが記録されているブロック32およびブロック34を読み出した後のデータ書き込み速度が0になるとき、バッファ17に記録されているデータの量は、大きく減少するため、バッファ17は、アンダフローを防止するには、所定以上の記憶容量が必要となる。
図23は、光ディスク8に記録されているファイルの他の構成例を説明する図である。この構成では、その一部または全部にファイルのデータが記録されているブロックは、必ず、ブロックの2分の1以上にファイルのデータが記録されるようになされている。
図24は、ファイルが図23に示すように構成されている場合におけるバッファ17のデータの量の変化を示す図である。図24(A)は、ブロックに記録されているファイルを説明する図である。ブロック51乃至ブロック54は、前述のように、その2分の1以上にファイルが記録されている。
図24(B)は、図24(A)に示されたブロックを読み出すときのバッファ17への書き込み速度を表す図である。ブロック51を読み出すとき、バッファ17への書き込み速度は、ブロック51が物理的に連続しているため、Rinの一定速度となる。同様に、ブロック52を読み出すとき、ブロック53を読み出すとき、およびブロック54を読み出すとき、バッファ17への書き込み速度は、Rinの一定速度となる。
ブロック51の読み出しを終了し、つぎにブロック52の読み出しを行うとき、ブロックが物理的に離間していれば、バッファ17への書き込み速度が0になる期間Ts4が存在する。同様に、ブロック52の読み出しを終了し、つぎにブロック53の読み出しを行うとき、バッファ17への書き込み速度が0になる期間Ts5が存在し、ブロック53の読み出しを終了し、つぎにブロック54の読み出しを行うとき、バッファ17への書き込み速度が0になる期間Ts6が存在する。
図24(C)は、バッファ17からのデータ読み出し速度を示す図である。データ読み出し速度は、常に一定の値Routである。図24(D)は、バッファ17に記憶されているデータの量の変化を示す図である。バッファ17へのデータ書き込み速度が0になるとき、バッファ17に記録されているデータの量は、急激に減少する。図22(D)の場合と比較し、ブロック51、ブロック52、ブロック53、およびブロック54は、一定量(1/2)以上のデータを記録しているため、バッファ17に記録されているデータの量が、0に近づく可能性は、図22(D)に示した場合より、少ない。
図25は、ファイル管理部6のファイルのブロックへの記録の処理を説明する図である。図25(A)に示すように、すでにブロック71乃至73にファイルのデータが記録されており、新たに、ブロック74にブロック74の2分の1より小さいデータ量のファイル75が記録される場合の処理を説明する。図25(B)に示すように、ブロック73に記憶されたファイルは、ブロック73の2分の1を占める前半部分81を残して分割され、後半部分82がブロック74の先頭に移動される。ファイル75は、ブロック74の後半部分82に続いて記録される。
以上のように、ファイルの一部または全部が記録されているブロックは、ブロックの2分の1以上にファイルが記録される。
以上の処理をまとめると、図26のフローチャートに示すようになる。すなわち、ステップS31において、ファイル管理部6は、記録するデータ量がブロックの1/2未満であるか否かを判定し、記録するデータ量がブロックの1/2未満であると判定された場合、ステップS32に進み、直前のブロックの後方の1/2のデータを分割し、次のブロックに記録させる。ステップS33において、ファイル管理部6は、そのブロックにブロックの1/2未満の量のデータを記録する。
ステップS34において、ファイル管理部6は、全てのデータを記録したか否かを判定し、全てのデータを記録していないと判定された場合、ステップS31に戻り、処理を繰り返す。
ステップS31において、記録するデータ量がブロックの1/2未満でないと判定された場合、ステップS35に進み、ファイル管理部6は、記録するデータ量が1ブロック分以下であるか否かを判定し、記録するデータ量が1ブロック分以下でないと判定された場合、ステップS36に進む。ステップS36において、ファイル管理部6は、1ブロック分のデータを記録し、ステップS34に進む。
ステップS35において、記録するデータ量が1ブロック分以下であると判定された場合、ステップS37に進み、ファイル管理部6は、そのデータを1ブロックに記録し、ステップS34に進む。
ステップS34において、全てのデータを記録したと判定された場合、処理は終了する。
図27は、ブロックへの記録されたファイルの分割の処理を説明する図である。図27(A)に示すように、ブロック91乃至93に1つのファイルが記録されており、このファイルをブロック91の始点からブロック92の分割点(ブロック92の1/2より前方に位置する)までのファイルと、ブロック92の分割点からブロック93の終点までのファイルに分割する場合の処理を説明する。図27(B)に示すように、ブロック92の始点から分割点までの部分95の前の部分が記憶されたブロック91のデータは、2分割され、その後半部分94は、ブロック92に移動される。ブロック92に移動された後半部分94に続いて、ブロック92の前半部分95が格納される。一方、ブロック92の分割点から終点までの部分96は、新たなブロック101に格納される。
図28は、ファイルの分割の他の処理例を説明する図である。図28(A)に示すように、ブロック111乃至114に記録されている1つのファイルを、ブロック112の1/2の位置より前に位置する分割点で分割する場合の処理を説明する。
図28(B)に示すように、ブロック111に、ブロック112の始点から分割点までの部分115を記録できる大きさの領域があれば、ブロック111のすでに記録されているファイルに続いて、部分115が記録される。ブロック112の始点からデータの最後までの部分116は、ブロック112の始点からの位置に移動される。全ての範囲に記録されたブロック113のデータは2分割され、その前半部分117は、ブロック112に移動され、ブロック112の部分116に続いて記録される。ブロック113の後半部分118は、ブロック113の始点からの位置に移動される。
図29は、ブロックへの記録されたファイルの分割のさらに異なる処理例を説明する図である。図29(A)に示すように、ブロック121乃至123に記録されている1つのファイルを、ブロック122の中間点を分割点として分割する場合の処理を説明する。図29(B)に示すように、ブロック122の分割点からデータの最後までの部分124は、新たなブロック131の先頭に格納される。全ての範囲に記録されたブロック123のファイルは2分割され、その前半部分125は、ブロック131に、部分124に続いて格納され、後半部分126は、ブロック123の先頭に移動される。
以上のように、ファイルが分割されても、ブロックは、その2分の1以上にファイルが記録される。
図27に示された、ブロックの始点から分割点までのデータの大きさがブロックの大きさの1/2未満であり、かつ、分割点から後ろのデータの大きさがブロックの大きさの1/2以上である場合のファイルの分割の処理は、図30のフローチャートに示すようになる。すなわち、ステップS41において、ファイル管理部6は、分割点のあるブロックの、分割点から後ろのデータを、新たなブロックに移動する。ステップS42において、ファイル管理部6は、分割点のあるブロックの直前のブロックの所定のデータを、分割点のあるブロックの始点からの位置に移動し、分割点のあるブロックの始点から分割点までデータをそのデータの後ろに移動する。
図28に示された、分割点のあるブロックの直前の空きの大きさが、分割点のあるブロックの始点から分割点までのデータの大きさ以上であり、かつ、分割点から後ろのデータの大きさがブロックの大きさの1/2未満である場合のファイルの分割の処理は、図31のフローチャートに示すようになる。ステップS51において、ファイル管理部6は、分割点のあるブロックの、ブロックの始点から分割点までデータを、分割点のあるブロックの直前のブロックの空きに移動する。ステップS52において、ファイル管理部6は、分割点のあるブロックの直後のブロックの所定のデータを、分割点のあるブロックのデータの後ろに移動する。
図29に示された、ブロックの始点から分割点までのデータの大きさがブロックの大きさの1/2以上であり、かつ、分割点から後ろのデータの大きさがブロックの大きさの1/2未満である場合のファイルの分割の処理は、図32のフローチャートに示すようになる。ステップS61において、ファイル管理部6は、分割点から後ろのデータを、新たなブロックに移動する。ステップS62において、ファイル管理部6は、分割点のあるブロックの直後のブロックの所定のデータを、新たなブロックのデータの後ろの位置に移動する。
以上においては、ブロックの始点から分割点までのデータの大きさがブロックの大きさの1/2以上であるか否かを基準としたが、(n-1)/n(n=2,3,4,5,・・)を基準としてもよい。
図33は、連続する3つのブロックの空き領域が、合わせて1ブロック以上ある場合の、ブロックの空き領域の圧縮の処理を説明する図である。図33(A)に示すように、ブロック141乃至143の空き領域は、合わせて1ブロック以上ある。ブロック142に記憶された内容を、ブロック141の空き領域の大きさと同じ大きさの部分144と残りの部分145に分割する。
図33(B)に示すように、ブロック142の部分144はブロック141の空き領域に移動される。ブロック142の部分145は、ブロック142の先頭に移動され、ブロック143のデータ146は、ブロック142に移動され、部分145に続けて格納される。ブロック143は、空きになる。
このように、ブロック141乃至142の空き領域を少なくし、ブロック143を空きにすることができる。
以上の処理をまとめると、図34のフローチャートになる。すなわち、ステップS71において、ファイル管理部6は、3つのブロックの空きの合計が、1ブロック以上であるか否かを判定し、3つのブロックの空きの合計が、1ブロック以上であると判定された場合、ステップS72に進み、中間のブロックから、先頭のブロックの空きに、その空きの相当するデータを移動する。ステップS73において、ファイル管理部6は、最後のブロックから、中間のブロックの空きに、その空きの相当するデータを移動し、処理を終了する。
ステップS71において、3つのブロックの空きの合計が、1ブロック以上でないと判定された場合、処理は終了する。
以上のように、ファイルの一部または全部が記録されているブロックは、ブロックの2分の1以上にファイルが記録され、書き込み速度が0になる期間が分散されるため、バッファ17の容量が少なくても出力が途切れない。
なお、上記したような処理を行うコンピュータプログラムをユーザに提供する提供媒体としては、磁気ディスク、CD-ROM、固体メモリなどの記録媒体の他、ネットワーク、衛星などの通信媒体を利用することができる。
1 記録再生装置, 2 ユーザ入出力部, 3 AV入出力部, 4 PCデータ入出力部, 5 システムコントロール部, 6 ファイル管理部, 7 ドライブ部, 8 光ディスク, 31乃至34,51乃至54,71乃至74,91乃至93,101,111乃至114,121乃至123,131,141乃至143 ブロック