JP4078571B2 - 記録再生装置、ファイル管理方法、並びに提供媒体 - Google Patents
記録再生装置、ファイル管理方法、並びに提供媒体 Download PDFInfo
- Publication number
- JP4078571B2 JP4078571B2 JP22970498A JP22970498A JP4078571B2 JP 4078571 B2 JP4078571 B2 JP 4078571B2 JP 22970498 A JP22970498 A JP 22970498A JP 22970498 A JP22970498 A JP 22970498A JP 4078571 B2 JP4078571 B2 JP 4078571B2
- Authority
- JP
- Japan
- Prior art keywords
- file
- data
- recording
- recorded
- record
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、記録再生装置、ファイル管理方法、並びに提供媒体に関し、特に、デイスク状記録媒体を使用する記録再生装置（VDR: Video Disc Recorder）に使用するファイルシステムに関する。
【０００２】
【従来の技術】
デイスク状記録媒体にデータを記録するためのファイルシステムとしては、ISO/IEC13346:1995, "Information technology - Volume and file structure of write-once and rewritable media using non-sequential recording for information interchange."が知られている。このファイルシステムは、各種データを記録するための汎用的なファイルシステムであり、個人が家庭内でデイスクに圧縮されたデジタルAV（音声、ビデオ）信号を記録するためのものでは無い。従って、圧縮されたデジタルAV（音声、ビデオ）信号を記録するには必ずしも十分なものではない。従って、AV信号を記録するに最適なファイルシステム、及びボリウムが求められている。
【０００３】
【発明が解決しようとする課題】
従って、個人が家庭内で簡単にデイスクにAV信号を記録再生するためのファイルシステムが必要である。
【０００４】
【課題を解決するための手段】
請求項１に記載の記録再生装置は、AVデータのファイルを記録する第１の記録手段と、ディスク状記録媒体に対して記録可能な情報の単位の長さを設定する設定手段と、ファイルに対応して、設定手段により設定された長さの単位のうち、そのファイルを記録するとき採用された単位の長さを識別する識別情報を含む、ファイルの管理情報を、論理ボリウムの少なくとも２個所に記録する第２の記録手段とを備えることを特徴とする。
【０００５】
請求項３に記載のファイル管理方法は、AVデータのファイルを記録する第１の記録ステップと、ディスク状記録媒体に対して記録可能な情報の単位の長さを設定する設定ステップと、ファイルに対応して、設定ステップの処理により設定された長さの単位のうち、そのファイルを記録するとき採用された単位の長さを識別する識別情報を含む、ファイルの管理情報を、論理ボリウムの少なくとも２個所に記録する第２の記録ステップとを含むことを特徴とする。
【０００６】
請求項４に記載の提供媒体は、AVデータのファイルを記録する第１の記録ステップと、ディスク状記録媒体に対して記録可能な情報の単位の長さを設定する設定ステップと、ファイルに対応して、設定ステップの処理により設定された長さの単位のうち、そのファイルを記録するとき採用された単位の長さを識別する識別情報を含む、ファイルの管理情報を、論理ボリウムの少なくとも２個所に記録する第２の記録ステップとを含む処理を実行させるコンピュータが読みとり可能なプログラムを提供することを特徴とする。
【００１０】
請求項１に記載の記録再生装置、請求項３に記載のファイル管理方法、および請求項４に記載の提供媒体においては、AVデータのファイルを記録し、ディスク状記録媒体に対して記録可能な情報の単位の長さを設定し、ファイルに対応して、設定された長さの単位のうち、そのファイルを記録するとき採用された単位の長さを識別する識別情報を含む、ファイルの管理情報を、論理ボリウムの少なくとも２個所に記録する。
【００１６】
【発明の実施の形態】
はじめに、ディスク状記録媒体のフォーマット方式について説明する。図１は、ディスク状記録媒体全体のフォーマットを説明する図である。ディスクは、長さが可変長の複数のアロケーションエクステントに分割される。アロケーションエクステントは、長さが固定の複数のブロックから構成される。ブロックは、所定の数の物理セクタから構成される。
【００１７】
図２は、アンカーディスクリプタについて説明する図である。ディスク内に、４つのアンカーディスクリプタが配置される。アンカーディスクリプタには、ボリウム管理用マネージメントインフォメーションエリアの位置が記録されている。ボリウム管理用マネージメントインフォメーションエリアのボリウムストラクチャディスクリプタには、フィジカルボリウムインフォメーション、パーテーションインフォメーション、ロジカルボリウムインフォメーション、およびパーテーションマップが含まれている。
【００１８】
ボリウムストラクチャディスクリプタには、ユーザエリアとしてのロジカルボリウムが記述されている。図３は、ロジカルボリウムを説明する図である。ロジカルボリウムには、ファイルシステムディスクリプタが、配置されている。ロジカルボリウムの先頭付近、および終了付近には、それぞれ、MIA(Management Information Area)が配置されている。MIAには、ファイルテーブル、アロケーションエクステントテーブル、アロケーションストラテジィテーブル、ディフェクトインフォメーションテーブル、エクステンデッドアトリビュートテーブルが含まれている。アロケーションエクステントの長さは、アロケーションストラテジィテーブルを構成するアロケーションストラテジィレコードに記述される。
【００１９】
ユーザは、ディスクにファイルのデータを記録する前に、そのディスクに記録するデータのアロケーションエクステントの長さを予め設定する。これにより、例えば、AVデータは、より長い長さのアロケーションエクステントのフォーマットで記録し、PCデータは短い長さのアロケーションエクステントのフォーマットで記録することが可能となる。AVデータは連続するデータであることが多いので、アロケーションエクステントの長さを長くした方が、データをより効率的に記録再生することができる。
【００２０】
図４は、アロケーションエクステントの長さの設定の処理を説明するフローチャートである。ステップＳ１１において、後述するドライブ部７は、ユーザからの設定入力に対応して、MIAに含まれるアロケーションストラテジィテーブルに、アロケーションエクステントの設定された長さに対応したアロケーションストラテジィレコードを書き込む。アロケーションストラテジィテーブルには、複数のアロケーションストラテジィレコードを書き込むことができる。図５は、アロケーションエクステントの長さをユーザが設定する画面の例を示す図である。アロケーションエクステントの長さとしては、4MByte以上，64KByte，2kByteなど任意の長さが設定可能であり、かつ、複数の長さの設定が可能である。そのディスクには、予め設定した長さのアロケーションエクステントのフォーマットの中から指定されたものでのみ記録が可能である。
【００２１】
このように、アロケーションエクステントの長さを設定し、ディスクに記録した後、そのディスクにデータを記録する場合の処理は、図６のフローチャートに示すようになる。ステップＳ２１において、ユーザは、これから記録するデータのアロケーションエクステントの長さを選択する。図７は、アロケーションエクステントの長さを選択する画面の例を表している。この長さとしては、そのディスクに予め設定された値だけが表示される。画面のボタンを操作することで、ボタンに対応するアロケーションエクステントの長さが、選択される。AVデータを記録するとき、PCデータを記録するときに較べて、より長いアロケーションエクステントを指定することで、より効率的なデータの記録が可能になる。アロケーションエクステントの長さの指定により、アロケーションストラテジィテーブル内に配置されたアロケーションストラテジィレコードが指定される。指定が完了すると、ステップＳ２２において、ドライブ部７は、入力されたデータをディスクに記録する。データの記録が完了すると、ステップＳ２３において、ドライブ部７は、ディスクにそのファイルのアロケーションエクステントの長さに対応した番号を記録する。後述するファイル管理部６は、アロケーションエクステントの長さに対応した番号を知ることにより、対応するアロケーションストラテジィレコードの内容を利用することができる。
【００２２】
後述する図１９のシステムコントロール部５が、ＡＶデータを記録しようとしているのか、ＰＣデータを記録しようとしているのかを判断することができる場合には、前述のステップＳ２１をユーザからの入力なしに行うことも可能である。
【００２３】
以上のように、ディスクにファイルが記録される。
【００２４】
ボリウムの構成について説明する。ディスクエクステント(DescExtent)は、後述のMIA内に記録されたディスクリプタ（descriptor）中の後述するMIB(Management Information Block)にアライメントされた領域を表現するのに用いられる。ディスクエクステントは表１に示す様式で記録する。
【００２５】
【表１】
【００２６】
オフセットフロムトップオブディスクリプタ(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エントリは表２に示す様式で記録する。
【００２８】
【表２】
【００２９】
フィジカルセクタナンバオブディフェクトセクタ(Physical Sector Number of Defect Sector :RBP 0)はスリッピングを行う物理セクタの物理セクタ番号を指定する。
【００３０】
SDLエントリ(Secondary Defect List Entry)は、ディフェクトマネージメントにおいてリニアリプレースメント行う物理セクタの物理セクタ番号とその代替として使用する物理セクタの物理セクタ番号を記録するのに用いる。SDLエントリは表３に示す様式で記録する。
【００３１】
【表３】
【００３２】
表３のフィジカルセクタナンバオブディフェクトセクタはリニアリプレースメントを行う物理セクタの物理セクタ番号を指定する。フィジカルセクタナンバオブスペアセクタ(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が最後についた数値は、１６進数を表す）をアンカーポイントとする。パーシャル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）の大きさは物理セクタサイズ以下で、表４に示す様式で記録される。
【００４９】
【表４】
【００５０】
シグニチャ（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マップは表５に示す様式で記録する。
【００５３】
【表５】
【００５４】
シグネチャ(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に対応する。表６は、マップエントリの値を示す表である。
【００５６】
【表６】
【００５７】
図８は、ボリウムストラクチャディスクリプタ（Volume Structure Descriptor）の構造を示す図である。ここで、@APSは、アライントゥフィジカルセクタ(Align to Physical Sector)を示し、そのデータは、物理セクタにアライメントすることを示す。また、アライメントに際し、直前に記録すべきデータが実際に記録された場所の次のバイトからそのセクタの終りまでの領域は、#00が設定される。
【００５８】
ボリウムストラクチャヘッダ（Volume Structure Descriptor Header）は、表７に従って記録される。
【００５９】
【表７】
【００６０】
シグネチャ(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）は表８に従って記録しなければならない。
【００６２】
【表８】
【００６３】
キャラクタセット(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）は、表９で示す様式で記録しなければならない。
【００６６】
【表９】
【００６７】
スタートフィジカルセクタナンバ(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)は、このパーティションの記録特性の状態を指定する。表１０は、アクセスタイプの内容を示す表である。
【００６８】
【表１０】
【００６９】
ユーゼジインフォメーション(Usage Information:RBP 17)は、このパーティションの利用状態を指定する。表１１は、ユーゼジインフォメーションの内容を示す表である。
【００７０】
【表１１】
【００７１】
リザーブド(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）は、表１２に示す様式で記録する。
【００７３】
【表１２】
【００７４】
スタートフィジカルセクタナンバ(Start Physical Sector Number:RBP 0)は、スペアエリアの先頭の物理セクタの物理セクタ番号を指定する。ナンバオブフィジカルセクタ(Number of Physical Sector:RBP 4) は、スペアを構成する物理セクタの数を指定する。リザーブド(Reserved:RBP 8)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
【００７５】
論理ボリウムインフォメーションヘッダ（Logical Volume Information Header）は、表１３で示す様式で記録される。
【００７６】
【表１３】
【００７７】
キャラクタセット(Charactor Set:RBP 0)は、論理ボリウムネームフィールドに記録された論理ボリウムの名前の文字コードを指定する。ロジカルボリュームネームサイズ(Logical Volume Name Size:RBP 2)は、論理ボリウムネームフィールドに指定された論理ボリウムの名前の大きさ(バイト数)を指定する。ロジカルボリュームネーム(Logical Volume Name:RBP 4)は、論理ボリウムの名前を指定する。ブートインジケータ(Boot Indicator:RBP 260)は、論理ボリウムからの起動に関する情報を指定する。ブートインジケータの内容を表１４に示す。ブートインジケータがアクティブであり、かつ、その先頭パーティションがその物理ボリウムにある論理ボリウムは、物理ボリウム中に2つ以上あってはならない。
【００７８】
【表１４】
【００７９】
ファイルシステムインジケータ(File System Indicator:RBP 262)は、この論理ボリウムで使用されているファイルシステムを指定する。ファイルシステムインジケータの内容を表１５に示す。
【００８０】
【表１５】
【００８１】
ロジカルセクタサイズ(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）は表１６に示す様式で記録される。
【００８３】
【表１６】
【００８４】
ボリュームアイデンティファイア(Volume Identifier:RBP 0)は、論理ボリウムを構成するパーティションが属している物理ボリウムの物理ボリウムインフォメーションに記録された物理ボリウム識別子を指定する。パーテーションナンバ(Partition Number:RBP 20)は、論理ボリウムを構成するパーティションのパーティション番号を指定する。リザーブド(Reserved:RBP 22)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
【００８５】
ディフェクトリストインフォメーションヘッダ（Defect List Information Header）は表１７に示す様式で記録される。
【００８６】
【表１７】
【００８７】
ナンバオブ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）は表１８に示す様式で記録される。
【００８９】
【表１８】
【００９０】
シグネチャ(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）の構造を図９に示す。
【００９２】
メディアインフォメーションディスクリプタヘッダ（Media Information Descriptor Header）は、表１９に示す様式で記録される。
【００９３】
【表１９】
【００９４】
シグネチャ(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）は、表２０に示す様式で記録される。
【００９６】
【表２０】
【００９７】
スタートフィジカルセクタナンバ(Start Physical Sector Number:RBP 0)は、ゾーンの先頭の物理セクタの物理セクタ番号を指定する。ナンバオブフィジカルセクタ(Number of Physical Sector:RBP 4)は、ゾーンを構成する物理セクタの数を指定する。リザーブド(Reserved:RBP 8)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
【００９８】
ドライブインフォメーションディスクリプタ（Drive Information Descriptor）の構造を図１０に示す。
【００９９】
ドライブインフォメーションディスクリプタヘッダ（Drive Information Descriptor Header）は、表２１に示す様式で記録される。
【０１００】
【表２１】
【０１０１】
シグネチャ(Signature:BP 0)のデータタイプフィールドは、21が設定される。ディスクリプタサイズ(Descriptor Size:BP 8)は、ドライブインフォメーションディスクリプタの大きさ(MIB数)を指定する。ストラテジィタイプ(Strategy Type:BP 10)は、ストラテジィタイプを指定する。リザーブド(Reserved:BP 11)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
【０１０２】
エクステンデッドデータディスクリプタ（Extended Data Descriptor）の構造を図１１に示す。ここで、@APSは、アライントゥフィジカルセクタ(Align to Physical Sector)を示し、そのデータは物理セクタにアライメントしなければならないことを示す。また、直前のデータの次のバイトからそのセクタの終りまでの領域は、#00が設定される。
【０１０３】
エクステンデッドデータディスクリプタヘッダ（Extended Data Descriptor Header）は、表２２に示す様式で記録される。
【０１０４】
【表２２】
【０１０５】
シグネチャ(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）について説明する。表２３は、VDRの場合のFAT, ISO9660(with Joliet), ISO/IEC13346, KIFSのハイブリッドディスクのボリューム構造の例を示す表である。表２３の◆は再配置不可能な位置固定情報であることを示す。
【０１０９】
【表２３】
【０１１０】
次に論理ボリウム上に構成される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)フィールドに表２４に示すように設定される。
【０１１３】
【表２４】
【０１１４】
メイン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では、ファイルテーブルの最初のファイルレコードがルートとなる図１２に示されるような木構造が構築される。図中の円は、一つのファイルレコードを表しており、ルートのファイルレコードはルートファイルレコード（Root File Record）と称される。参照すべきデータを持たないファイルレコードは、ディレクトリと称され、データを持つファイルレコードはファイルと称される。ディレクトリばかりでなく、ファイルも子ファイルレコードを有することが出来る。この階層構造は、図１３に示されるようにチャイルドリンク（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)が設定される。シグネチャは表２５に示すように記録される。
【０１２８】
【表２５】
【０１２９】
アイデンティフィケーション(Identification:RBP 0)は、文字列"AVFS"がISO/IEC 646に従って設定される。バージョン(Version:RBP 4)は、バージョン番号を指定し、1が設定される。データタイプ(Data type:RBP 5)は、データ構造体の種類を指定する。データ構造体の種類により、表２６に示される値が設定される。
【０１３０】
【表２６】
【０１３１】
リザーブド(Reserved:RBP 6)は、拡張のために予約され、#00が設定される。シグネチャは、クラッシュリカバリのときデータ構造体を識別する為に使われる。
【０１３２】
AVファイルシステムディスクリプタ（AV File System Descriptor）は、表２７に示すように記録される。
【０１３３】
【表２７】
【０１３４】
シグネチャのデータタイプフィールドは、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マップは、表２８に示すように記録される。
【０１３７】
【表２８】
【０１３８】
シグネチャ(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...に対応する。
【０１４１】
マップエントリの値は、表２９に示す意味を有する。
【０１４２】
【表２９】
【０１４３】
もしデータ構造体が論理セクタサイズに等しいかあるいは小さく、1つのMIB内に格納される場合、そのMIBに対応するマップエントリに#FFFFが、セットされる。データ構造体が複数のMIBにわたって記録される場合、最後以外のMIBに対応するマップエントリには次のMIBのMIB番号が、最後のMIBに対応するマップエントリには#FFFFがセットされる。マップエントリの値が#FFF1であるMIBは、そのブロックが未使用である事を示し、データ構造体が新しいMIBを必要とする場合に使用する事が出来る。マップエントリの値が#FFF0であるMIBは、その使用に問題がある(欠陥セクタなど)ことを表す。
【０１４４】
ファイルテーブル（File Table）は図１４に示すようにファイルテーブルヘッダとファイルテーブルデータから構成される。ファイルテーブルデータの構造はファイルテーブルヘッダのFile Table Structure Typeフィールドによって決まる。
【０１４５】
ファイルテーブルヘッダ（File Table Header）は、表３０に示すように記録される。
【０１４６】
【表３０】
【０１４７】
シグネチャ(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の場合、ファイルテーブルは図１５に示すようにファイルテーブルヘッダと1個以上のファイルレコードから構成される。ファイルレコードは、0から始まる連続、昇順の番号が付され、この番号は、ファイルレコード番号と称される。ファイルレコードのリストは次のレコードのファイルレコード番号をネクストリンク（Next Link）フィールドに設定する事により作られ、このリストはファイルレコードチェインと称される。ファイルテーブル内の使用されてないすべてのファイルレコードは、フリーファイルレコードチェインと称されるファイルレコードチェインを作成する。
【０１４９】
ファイルテーブルストラクチャタイプが0の場合、ファイルテーブルヘッダ（File Table Header）は表３１に示すように記録されなければならない。
【０１５０】
【表３１】
【０１５１】
シグネチャ(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）は、表３２に示すように記録されなければならない。
【０１５３】
【表３２】
【０１５４】
ファイル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）フィールドは、表３３に示すように記録される。
【０１５７】
【表３３】
【０１５８】
バリッド(Valid:Bit 0)は、このファイルレコードが有効なレコードであるかどうかを表し、0の場合、このファイルレコードが使われていないことを表し、ファイルレコードは、フリーファイルレコードチェイン中にある。バリッドが、1の場合、このファイルレコードが使用されていることを表し、ルートファイルレコードからチャイルドリンク, ネックストリンクを経て到達する事ができる。データロケーションタイプ(Data Location Type:Bit 0-1)は、データロケーション(Data Location:RBP 24)のフォーマットを指定する。データロケーションタイプが00の場合、データロケーションは参照するものがない事を示す(ファイルレコードがディレクトリの場合は、この値をセットする)。データロケーションタイプが01の場合、データロケーションは、アロケーションエクステントレコードチェインの先頭のアロケーションエクステントレコード番号とアロケーションストラテジィ番号を表３４に示すフォーマットで表される。データロケーションタイプが10の場合、ファイルレコードはサブファイルであることを表し、データロケーションは、ペアレントファイルレコードのデータロケーションが表すデータの先頭からのオフセットがUint64で表される。11のデータロケーションタイプは、拡張のために予約されている。
【０１５９】
【表３４】
【０１６０】
プロテクテッド(Protected:Bit 3)は、このファイルレコードがプロテクトされていることを表す。ソーテッド(Sorted:Bit 4)は、このファイルレコードの属するファイルレコードチェインがファイルタイプの若い順にソートされ、さらに同じファイルタイプの中ではファイルIDの若い順にソートされている事を表す。リザーブド(Reserved:Bit 5-31)は、拡張のために予約されている。
【０１６１】
アロケーションエクステントテーブル（Structure of the Allocation Extents Table）は、図１６に示すようにアロケーションエクステントテーブルヘッダとアロケーションエクステントレコードから構成される。アロケーションエクステントレコードには0から始まる連続、昇順の番号が付される。この番号は、アロケーションエクステントレコード番号と称される。次のレコードのアロケーションエクステントレコード番号をネクストアロケーションエクステントレコードフィールドに設定する事により、アロケーションエクステントレコードのリストはつくられる。このリストはアロケーションエクステントレコードチェインと称される。
【０１６２】
アロケーションエクステントテーブルヘッダ（Allocation Extents Table Header）は、表３５に示すように記録される。
【０１６３】
【表３５】
【０１６４】
シグネチャ(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）は、アロケーションエクステントの開始位置、終了位置、属性、アロケーションエクステントレコードチェインを構成する次のアロケーションエクステントレコードの位置を表す。アロケーションエクステントレコードは、表３６に示すように記録される。
【０１６７】
【表３６】
【０１６８】
スタートロジカルセクタナンバ(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)の表す値は、表３７に示す意味を有する。
【０１７０】
【表３７】
【０１７１】
アロケーションエクステントレコードステータス (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ファイルシステムがこの論理ボリウムでデータを配置するのに使用しているすべてのアロケーションストラテジィを指定する。アロケーションストラテジィテーブルは図１７に示すようにアロケーションストラテジィテーブルヘッダとアロケーションストラテジィレコードから構成される。
【０１７４】
アロケーションストラテジィテーブルヘッダ（Allocation Strategy Table Header）は、表３８に示すように記録される。
【０１７５】
【表３８】
【０１７６】
シグネチャ(Signature:BP 0)のデータタイプフィールドは、5が設定される。ナンバオブアロケーションストラテジィレコード(Number of Allocation Strategy Record:BP 8)は、アロケーションストラテジィ テーブル中のアロケーションストラテジィレコードの数を指定する。リザーブド(Reserved:RBP 10)は、拡張のために予約され、#00が設定される。
【０１７７】
アロケーションストラテジィレコードは、アロケーションストラテジィを指定するのに使用される。アロケーションストラテジィレコードは、表３９に示すように記録される。
【０１７８】
【表３９】
【０１７９】
レングスオブアロケーションストラテジィレコード(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においては、次の条件を満足する。第１に、アロケーションエクステントは、アロケーションストラテジィレコードのスタートロジカルセクタナンバ(Start Logical Sector Number:RBP 8)およびエンドロジカルセクタナンバ(End Logical Sector Number:RBP 12)で指定された領域内に配置されなければならない。第２に、論理セクタの一部が、あるアロケーションエクステントに割り当てられている場合、その論理セクタのどのバイトも別のアロケーションエクステントに属さない。第３に、アロケーションエクステントの先頭と論理セクタの先頭は一致する。アロケーションストラテジィタイプ 0のアロケーションストラテジィレコードは、表４０に示すように記録される。
【０１８１】
【表４０】
【０１８２】
レングスオブアロケーションストラテジィレコード(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のアロケーションストラテジィレコードは、表４１に示すように記録される。
【０１８４】
【表４１】
【０１８５】
レングスオブアロケーションストラテジィレコード(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)で指定された数のゾーンインフォメーションレコードが設定される。ゾーンインフォメーションレコードは、表４２に示すように記録される。
【０１８６】
【表４２】
【０１８７】
スタートロジカルセクタナンバ(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）は論理ボリウム中の欠陥セクタの論理セクタ番号を記録する。ディフェクトインフォメーションテーブルは、表４３に示すように記録される。
【０１８９】
【表４３】
【０１９０】
シグネチャ(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）は、図１８に示すようにエクステンデッドアトリビュートテーブルヘッダとエクステンデッドアトリビュートレコードから構成される。エクステンデッドアトリビュートテーブル中のエクステンデッドアトリビュートレコードは、0から始まる連続、昇順の番号が付され、この番号は、エクステンデッドアトリビュートレコード番号と称される。エクステンデッドアトリビュートレコードのリストは、ネクストエクステンデッドアトリビュートレコードフィールドに次のレコードを設定する事により作成され、このリストは、エクステンデッドアトリビュートレコードチェインと称される。エクステンデッドアトリビュートテーブル内の使用されてないエクステンデッドアトリビュートレコードは、フリーエクステンデッドアトリビュートレコードチェインと呼ばれるリストを作成する。
【０１９２】
エクステンデッドアトリビュートテーブルヘッダ（Extended Attribute Table Header）は、表４４に示すように記録される。
【０１９３】
【表４４】
【０１９４】
シグネチャ(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）は、表４５に示すように記録される。
【０１９６】
【表４５】
【０１９７】
ネクストエクステンデッドアトリビュートレコード(Next Extended Attribute Record:RBP 0)は、エクステンデッドアトリビュートレコードチェインを構成する次のエクステンデッドアトリビュートレコード番号を指定し、このエクステンデッドアトリビュートレコードが最後のエクステンデッドアトリビュートレコードである場合、#FFFFがセットされる。
【０１９８】
既存のファイルシステムの多くはメディアの欠陥セクタ処理をファイルシステムの下に位置するレイヤ(例えばドライブ内部の交替処理)で行う事を前提に設計されている。これらのファイルシステムでは欠陥セクタがどこにあるのかが分からず、欠陥がない部分ではドライブの生の転送速度でデータにアクセスできるが、交替処理が行われている部分ではそれよりもはるかに低い転送速度でしかアクセスが出来ない。
【０１９９】
従来のコンピュータ用途では平均アクセス時間の向上が要求される事はあっても個々のアクセス時間の見積もりが要求される事はなかったため上記のような構成でも問題はなかった。しかし、オーディオ, ビデオ用途ではデータを一定時間内に一定量供給できなければ音声や映像を正しく記録再生する事ができないため、ファイルシステムがデータアクセスにかかる時間の見積もりを行える事が必要となってきた。
【０２００】
そこで本ファイルシステムでは欠陥セクタ処理を下のレイヤで行わなくても良いという前提を導入し、ファイルシステムがデータのアクセスにかかる時間を正確に見積もる事が出来るようにした。これに伴い、本ファイルシステムでは従来のファイルシステムにはなかった欠陥セクタ処理の為のフィールドやフラグが用意され、これを使って欠陥セクタの処理が行う事が出来る。ここでは本ファイルシステムに用意された機能を使って欠陥セクタ処理を行う方法の一例を解説する。
【０２０１】
一般に欠陥セクタが検出されるのは次のいずれかである。第１に、書き込み中にエラーが発生し欠陥セクタが検出される。第２に、書き込みは正常終了したが、書き込み直後にその部分を読み出した際にエラーが検出される。第３に、書き込み、および書き込み直後の読み出しは正常終了したが、時間を経て読み出しを行った時にエラーが検出される。
【０２０２】
第１および第２の場合は、書き込み直後に読み出しを行い、正しく書き込めた事を確認する(Write and Verify)操作を行うことにより書き込み時に検出、対応できる。
【０２０３】
第３の場合は、光ディスクにおけるごみ、傷による障害などで発生するケースである。このケースについては完全な対応策は存在しないが、多重書きを行う事により、データロスの可能性を著しく下げる事が出来る。本ファイルシステムは、主にこのWrite and Verifyと多重書きの２つの手法を使って欠陥セクタの処理を行う。
【０２０４】
ボリウム構造は、ボリウムストラクチャディスクリプタ(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のアロケーションエクステントとして、ディフェクティブアロケーションエクステントレコードチェインに登録される。
【０２１１】
図１９は、本発明の記録再生装置１の一実施の形態の構成を示すブロック図である。記録再生装置１は、光ディスク８が装着され、光ディスク８に外部から供給されたビデオ信号およびオーディオ信号並びにPC(Personal Computer)データを記録するか、または、光ディスク８に記録されている信号を読み取り、外部に出力する。
【０２１２】
ユーザ入出力部２は、キーパネル１１およびLCD(Liquid Crystal Display)１２を有する。キーパネル１１は、ユーザの操作に応じた信号を発生し、システムコントロール部５に供給するようになされている。LCD１２は、システムコントロール部５から供給された信号に基づき、記録再生装置１の状態または記録再生装置１に装着された光ディスク８に関する情報等を表示する。
【０２１３】
AV入出力部３は、エンコーダ/デコーダ１３および１４並びにマルチプレクサ/デマルチプレクサ１５を有し、システムコントロール部５から供給された信号に基づき、エンコーダ/デコーダ１３および１４並びにマルチプレクサ/デマルチプレクサ１５を制御する。また、AV入出力部３は、システムコントロール部５にエンコーダ/デコーダ１３および１４並びにマルチプレクサ/デマルチプレクサ１５の状態を示す信号を供給する。
【０２１４】
エンコーダ/デコーダ１３は、記録時において、外部から供給されたビデオ信号を圧縮（エンコード）して、ビデオ信号に対応する所定の方式のビデオデータをマルチプレクサ/デマルチプレクサ１５に出力し、再生時において、マルチプレクサ/デマルチプレクサ１５から供給された所定の方式のビデオデータを伸張（デコード）して外部に出力する。エンコーダ/デコーダ１４は、記録時において、外部から供給されたオーディオ信号を圧縮（エンコード）して、オーディオ信号に対応する所定の方式のオーディオデータをマルチプレクサ/デマルチプレクサ１５に出力し、再生時において、マルチプレクサ/デマルチプレクサ１５から供給された所定の方式のオーディオデータをを伸張（デコード）して外部に出力する。
【０２１５】
マルチプレクサ/デマルチプレクサ１５は、記録時において、エンコーダ/デコーダ１３および１４から供給された所定の方式のビデオデータおよびオーディオデータを多重化し、ドライブ部７に出力するようになされている。また、再生時において、ドライブ部７から供給された多重化されたビデオデータおよびオーディオデータを分離し、ビデオデータをエンコーダ/デコーダ１３に、オーディオデータをエンコーダ/デコーダ１４に出力するようになされている。
【０２１６】
PCデータ入出力部４は、インターフェース１６を有し、システムコントロール部５から供給された信号に基づき、インターフェース１６を制御し、システムコントロール部５にインターフェース１６の状態を示す信号を出力する。インターフェース１６は、外部のパーソナルコンピュータ（図示せず）等から供給された所定の形式のPCデータを入力し、ドライブ部７が読み取り可能なデータに変更し、ドライブ部７に出力する。インターフェース１６は、また、ドライブ部７から供給されたデータを所定の形式で、外部のパーソナルコンピュータ等に出力するようになされている。
【０２１７】
システムコントロール部５は、ユーザ入出力部２、AV入出力部３、PCデータ入出力部４、およびファイル管理部６それぞれの状態に基づき、ユーザ入出力部２、AV入出力部３、PCデータ入出力部４、およびファイル管理部６を制御するようになされている。
【０２１８】
ファイル管理部６は、システムコントロール部５からの信号に基づき、ドライブ部７を制御し、ドライブ部７の状態に応じた信号をシステムコントロール部５に供給するようになされている。
【０２１９】
ドライブ部７は、バッファ１７、ECC回路１８、変調/復調回路１９、およびピックアップ２０を有し、ファイル管理部６からの信号に基づき、バッファ１７、ECC回路１８、変調/復調回路１９、およびピックアップ２０を動作させ、光ディスク８に信号を記録し、または光ディスク８から信号を読み出すようになされている。
【０２２０】
バッファ１７は、AV入出力部３またはPCデータ入出力部４から供給されたデータを一時的に記憶し、データが途切れないように、ECC(Error Correction Code)回路１８にデータを出力し、また、ECC回路１８から供給されたデータを一時的に記憶し、データが途切れないように、AV入出力部３またはPCデータ入出力部４に供給するようになされている。
【０２２１】
ECC回路１８は、バッファ１７から供給されたデータにECCを付加して、変調/復調回路１９に出力し、また、変調/復調回路１９から供給されたデータを、ECCを基に誤り訂正した後、バッファ１７に出力するようになされている。
【０２２２】
変調/復調回路１９は、ECC回路１８から供給されたデータを所定の方式に変調してピックアップ２０に出力し、ピックアップ２０から供給されたデータを所定の方式に基づいて復調し、ECC回路１８に出力するようになされている。
【０２２３】
ピックアップ２０は、変調/復調回路１９から供給されたデータに基づき、記録再生装置１に装着された光ディスク８にデータを記録し、または光ディスク８に記録されたデータを読み取り、変調/復調回路１９に出力するようになされている。
【０２２４】
図２０は、再生のときの、バッファ１７に記録されているデータの量とバッファ１７に書き込まれるデータの速度の関係を示す図である。バッファ１７から出力されるデータの読み出し速度Routは、エンコーダ/デコーダ１３および１４が信号の出力を途切れさせないようにするため、所定の値以上の一定値となるように制御される。バッファ１７に供給されるデータのデータ書き込み速度は、光ディスク８の所定のファイルが記録されているセクタを読み取っているとき、図２０（Ｂ）に示すように、一定の値Rinになる。一方、データ書き込み速度は、ピックアップ２０が光ディスク８のトラックの間を移動しているとき、または所定のセクタがピックアップ２０の読み取り可能な位置に来るまで光ディスク８の回転を待っているとき（図２０（Ｂ）の時間Tsの間）、0になる。
【０２２５】
このため、バッファ１７へのデータ書き込み速度が0になるとき、バッファ１７に記録されているデータの量は、読み出し速度Routで読み出しされるだけとなるため、図２０（Ａ）に示されるように、急激に減少する。バッファ１７の記憶可能なデータ量は、所定の期間、データ書き込みが無くとも、データの読み出しが途切れないように、Rin、およびデータの読み出し速度により決定される。
【０２２６】
図２１は、光ディスク８に記録されているファイルの構成を説明する図である。ブロックは、ディスク全体を等しい大きさに分割したもので、ブロック内が物理的に連続で、かつ、ブロック内ではRinの速度でデータの転送が実行される。ファイルのデータは、１または複数のブロックに記録される。従って、ブロックは、ファイルの一部または全部のデータが記録されているブロック、またはファイルのデータが記録されていないブロックにわかれる。ブロックに記録されているファイルのデータ量がブロックの大きさより小さいとき、そのファイルの直前のブロックは、その全てにデータが記録されている。
【０２２７】
図２２は、ファイルの構成とバッファ１７に記憶されたデータの量を示す図である。図２２（Ａ）は、ブロックに記録されているファイルを説明する図である。ブロック３１は、その全てにファイルのデータが記録されている。ブロック３１に連続するブロック３２は、その一部にファイルのデータが記録されている。ブロック３３は、その全てにファイルのデータが記録されている。ブロック３３に連続するブロック３４は、その一部にファイルのデータが記録されている。
【０２２８】
図２２（Ｂ）は、図２２（Ａ）に示されたブロックを読み出すときのバッファ１７への書き込み速度を表す図である。ブロック３１を読み出すとき、バッファ１７への書き込み速度は、ブロック３１が物理的に連続しているため、Rinの一定速度となる。同様に、ブロック３２を読み出すとき、ブロック３３を読み出すとき、およびブロック３４を読み出すとき、バッファ１７への書き込み速度は、Rinの一定速度となる。
【０２２９】
ブロック３１の読み出しを終了し、つぎにブロック３２の読み出しを行うとき、ブロック３１とブロック３２が物理的に連続しているとは限らないため、連続していなければ、ピックアップ２０は、光ディスク８のトラックの間を移動するか、または所定のセクタがピックアップ２０の読み取り可能な位置に来るまで光ディスク８の回転を待つ。このため、バッファ１７への書き込み速度が0になる期間Ts１が存在する。同様に、ブロック３２の読み出しを終了し、つぎにブロック３３の読み出しを行うとき、バッファ１７への書き込み速度が0になる期間Ts２が存在し、ブロック３３の読み出しを終了し、つぎにブロック３４の読み出しを行うとき、バッファ１７への書き込み速度が0になる期間Ts３が存在する。
【０２３０】
図２２（Ｃ）は、バッファ１７からのデータ読み出し速度を示す図である。データ読み出し速度は、常に一定の値Routである。図２２（Ｄ）は、バッファ１７に記憶されているデータの量を示す図である。図２０（Ａ）に示される場合と同様に、バッファ１７のデータ量は、書き込み速度Rinと読み出し速度Routの差に対応する速度で増加し、バッファ１７へのデータ書き込み速度が0になるとき、バッファ１７に記録されているデータの量は、読み出しだけとなるので、急激に減少する。特に、その一部だけにファイルのデータが記録されているブロック３２およびブロック３４を読み出した後のデータ書き込み速度が0になるとき、バッファ１７に記録されているデータの量は、大きく減少するため、バッファ１７は、アンダフローを防止するには、所定以上の記憶容量が必要となる。
【０２３１】
図２３は、光ディスク８に記録されているファイルの他の構成例を説明する図である。この構成では、その一部または全部にファイルのデータが記録されているブロックは、必ず、ブロックの２分の１以上にファイルのデータが記録されるようになされている。
【０２３２】
図２４は、ファイルが図２３に示すように構成されている場合におけるバッファ１７のデータの量の変化を示す図である。図２４（Ａ）は、ブロックに記録されているファイルを説明する図である。ブロック５１乃至ブロック５４は、前述のように、その２分の１以上にファイルが記録されている。
【０２３３】
図２４（Ｂ）は、図２４（Ａ）に示されたブロックを読み出すときのバッファ１７への書き込み速度を表す図である。ブロック５１を読み出すとき、バッファ１７への書き込み速度は、ブロック５１が物理的に連続しているため、Rinの一定速度となる。同様に、ブロック５２を読み出すとき、ブロック５３を読み出すとき、およびブロック５４を読み出すとき、バッファ１７への書き込み速度は、Rinの一定速度となる。
【０２３４】
ブロック５１の読み出しを終了し、つぎにブロック５２の読み出しを行うとき、ブロックが物理的に離間していれば、バッファ１７への書き込み速度が0になる期間Ts４が存在する。同様に、ブロック５２の読み出しを終了し、つぎにブロック５３の読み出しを行うとき、バッファ１７への書き込み速度が0になる期間Ts５が存在し、ブロック５３の読み出しを終了し、つぎにブロック５４の読み出しを行うとき、バッファ１７への書き込み速度が0になる期間Ts６が存在する。
【０２３５】
図２４（Ｃ）は、バッファ１７からのデータ読み出し速度を示す図である。データ読み出し速度は、常に一定の値Routである。図２４（Ｄ）は、バッファ１７に記憶されているデータの量の変化を示す図である。バッファ１７へのデータ書き込み速度が0になるとき、バッファ１７に記録されているデータの量は、急激に減少する。図２２（Ｄ）の場合と比較し、ブロック５１、ブロック５２、ブロック５３、およびブロック５４は、一定量（1/2）以上のデータを記録しているため、バッファ１７に記録されているデータの量が、０に近づく可能性は、図２２（Ｄ）に示した場合より、少ない。
【０２３６】
図２５は、ファイル管理部６のファイルのブロックへの記録の処理を説明する図である。図２５（Ａ）に示すように、すでにブロック７１乃至７３にファイルのデータが記録されており、新たに、ブロック７４にブロック７４の２分の１より小さいデータ量のファイル７５が記録される場合の処理を説明する。図２５（Ｂ）に示すように、ブロック７３に記憶されたファイルは、ブロック７３の２分の１を占める前半部分８１を残して分割され、後半部分８２がブロック７４の先頭に移動される。ファイル７５は、ブロック７４の後半部分８２に続いて記録される。
【０２３７】
以上のように、ファイルの一部または全部が記録されているブロックは、ブロックの２分の１以上にファイルが記録される。
【０２３８】
以上の処理をまとめると、図２６のフローチャートに示すようになる。すなわち、ステップＳ３１において、ファイル管理部６は、記録するデータ量がブロックの1/2未満であるか否かを判定し、記録するデータ量がブロックの1/2未満であると判定された場合、ステップＳ３２に進み、直前のブロックの後方の1/2のデータを分割し、次のブロックに記録させる。ステップＳ３３において、ファイル管理部６は、そのブロックにブロックの1/2未満の量のデータを記録する。
【０２３９】
ステップＳ３４において、ファイル管理部６は、全てのデータを記録したか否かを判定し、全てのデータを記録していないと判定された場合、ステップＳ３１に戻り、処理を繰り返す。
【０２４０】
ステップＳ３１において、記録するデータ量がブロックの1/2未満でないと判定された場合、ステップＳ３５に進み、ファイル管理部６は、記録するデータ量が１ブロック分以下であるか否かを判定し、記録するデータ量が１ブロック分以下でないと判定された場合、ステップＳ３６に進む。ステップＳ３６において、ファイル管理部６は、１ブロック分のデータを記録し、ステップＳ３４に進む。
【０２４１】
ステップＳ３５において、記録するデータ量が１ブロック分以下であると判定された場合、ステップＳ３７に進み、ファイル管理部６は、そのデータを１ブロックに記録し、ステップＳ３４に進む。
【０２４２】
ステップＳ３４において、全てのデータを記録したと判定された場合、処理は終了する。
【０２４３】
図２７は、ブロックへの記録されたファイルの分割の処理を説明する図である。図２７（Ａ）に示すように、ブロック９１乃至９３に１つのファイルが記録されており、このファイルをブロック９１の始点からブロック９２の分割点（ブロック９２の1/2より前方に位置する）までのファイルと、ブロック９２の分割点からブロック９３の終点までのファイルに分割する場合の処理を説明する。図２７（Ｂ）に示すように、ブロック９２の始点から分割点までの部分９５の前の部分が記憶されたブロック９１のデータは、２分割され、その後半部分９４は、ブロック９２に移動される。ブロック９２に移動された後半部分９４に続いて、ブロック９２の前半部分９５が格納される。一方、ブロック９２の分割点から終点までの部分９６は、新たなブロック１０１に格納される。
【０２４４】
図２８は、ファイルの分割の他の処理例を説明する図である。図２８（Ａ）に示すように、ブロック１１１乃至１１４に記録されている１つのファイルを、ブロック１１２の1/2の位置より前に位置する分割点で分割する場合の処理を説明する。
【０２４５】
図２８（Ｂ）に示すように、ブロック１１１に、ブロック１１２の始点から分割点までの部分１１５を記録できる大きさの領域があれば、ブロック１１１のすでに記録されているファイルに続いて、部分１１５が記録される。ブロック１１２の始点からデータの最後までの部分１１６は、ブロック１１２の始点からの位置に移動される。全ての範囲に記録されたブロック１１３のデータは２分割され、その前半部分１１７は、ブロック１１２に移動され、ブロック１１２の部分１１６に続いて記録される。ブロック１１３の後半部分１１８は、ブロック１１３の始点からの位置に移動される。
【０２４６】
図２９は、ブロックへの記録されたファイルの分割のさらに異なる処理例を説明する図である。図２９（Ａ）に示すように、ブロック１２１乃至１２３に記録されている１つのファイルを、ブロック１２２の中間点を分割点として分割する場合の処理を説明する。図２９（Ｂ）に示すように、ブロック１２２の分割点からデータの最後までの部分１２４は、新たなブロック１３１の先頭に格納される。全ての範囲に記録されたブロック１２３のファイルは２分割され、その前半部分１２５は、ブロック１３１に、部分１２４に続いて格納され、後半部分１２６は、ブロック１２３の先頭に移動される。
【０２４７】
以上のように、ファイルが分割されても、ブロックは、その２分の１以上にファイルが記録される。
【０２４８】
図２７に示された、ブロックの始点から分割点までのデータの大きさがブロックの大きさの1/2未満であり、かつ、分割点から後ろのデータの大きさがブロックの大きさの1/2以上である場合のファイルの分割の処理は、図３０のフローチャートに示すようになる。すなわち、ステップＳ４１において、ファイル管理部６は、分割点のあるブロックの、分割点から後ろのデータを、新たなブロックに移動する。ステップＳ４２において、ファイル管理部６は、分割点のあるブロックの直前のブロックの所定のデータを、分割点のあるブロックの始点からの位置に移動し、分割点のあるブロックの始点から分割点までデータをそのデータの後ろに移動する。
【０２４９】
図２８に示された、分割点のあるブロックの直前の空きの大きさが、分割点のあるブロックの始点から分割点までのデータの大きさ以上であり、かつ、分割点から後ろのデータの大きさがブロックの大きさの1/2未満である場合のファイルの分割の処理は、図３１のフローチャートに示すようになる。ステップＳ５１において、ファイル管理部６は、分割点のあるブロックの、ブロックの始点から分割点までデータを、分割点のあるブロックの直前のブロックの空きに移動する。ステップＳ５２において、ファイル管理部６は、分割点のあるブロックの直後のブロックの所定のデータを、分割点のあるブロックのデータの後ろに移動する。
【０２５０】
図２９に示された、ブロックの始点から分割点までのデータの大きさがブロックの大きさの1/2以上であり、かつ、分割点から後ろのデータの大きさがブロックの大きさの1/2未満である場合のファイルの分割の処理は、図３２のフローチャートに示すようになる。ステップＳ６１において、ファイル管理部６は、分割点から後ろのデータを、新たなブロックに移動する。ステップＳ６２において、ファイル管理部６は、分割点のあるブロックの直後のブロックの所定のデータを、新たなブロックのデータの後ろの位置に移動する。
【０２５１】
以上においては、ブロックの始点から分割点までのデータの大きさがブロックの大きさの1/2以上であるか否かを基準としたが、(n-1)/n(n=2,3,4,5,・・)を基準としてもよい。
【０２５２】
図３３は、連続する３つのブロックの空き領域が、合わせて１ブロック以上ある場合の、ブロックの空き領域の圧縮の処理を説明する図である。図３３（Ａ）に示すように、ブロック１４１乃至１４３の空き領域は、合わせて１ブロック以上ある。ブロック１４２に記憶された内容を、ブロック１４１の空き領域の大きさと同じ大きさの部分１４４と残りの部分１４５に分割する。
【０２５３】
図３３（Ｂ）に示すように、ブロック１４２の部分１４４はブロック１４１の空き領域に移動される。ブロック１４２の部分１４５は、ブロック１４２の先頭に移動され、ブロック１４３のデータ１４６は、ブロック１４２に移動され、部分１４５に続けて格納される。ブロック１４３は、空きになる。
【０２５４】
このように、ブロック１４１乃至１４２の空き領域を少なくし、ブロック１４３を空きにすることができる。
【０２５５】
以上の処理をまとめると、図３４のフローチャートになる。すなわち、ステップＳ７１において、ファイル管理部６は、３つのブロックの空きの合計が、１ブロック以上であるか否かを判定し、３つのブロックの空きの合計が、１ブロック以上であると判定された場合、ステップＳ７２に進み、中間のブロックから、先頭のブロックの空きに、その空きの相当するデータを移動する。ステップＳ７３において、ファイル管理部６は、最後のブロックから、中間のブロックの空きに、その空きの相当するデータを移動し、処理を終了する。
【０２５６】
ステップＳ７１において、３つのブロックの空きの合計が、１ブロック以上でないと判定された場合、処理は終了する。
【０２５７】
以上のように、ファイルの一部または全部が記録されているブロックは、ブロックの２分の１以上にファイルが記録され、書き込み速度が0になる期間が分散されるため、バッファ１７の容量が少なくても出力が途切れない。
【０２５８】
なお、上記したような処理を行うコンピュータプログラムをユーザに提供する提供媒体としては、磁気ディスク、CD-ROM、固体メモリなどの記録媒体の他、ネットワーク、衛星などの通信媒体を利用することができる。
【０２５９】
【発明の効果】
請求項１に記載の記録再生装置、請求項３に記載のファイル管理方法、および請求項４に記載の提供媒体によれば、AVデータのファイルを記録し、ディスク状記録媒体に対して記録可能な情報の単位の長さを設定し、ファイルに対応して、設定された長さの単位のうち、そのファイルを記録するとき採用された単位の長さを識別する識別情報を含む、ファイルの管理情報を、論理ボリウムの少なくとも２個所に記録するようにしたので、個人が家庭内で圧縮ビデオ、圧縮音声信号を簡単に記録再生することができる。
【図面の簡単な説明】
【図１】ディスク状記録媒体全体のフォーマットを説明する図である。
【図２】アンカーディスクリプタについて説明する図である。
【図３】ロジカルボリウムを説明する図である。
【図４】アロケーションエクステントの長さの設定の処理を説明するフローチャートである。
【図５】アロケーションエクステントの長さを設定する画面の例を示す図である。
【図６】ファイルの記録の処理を説明するフローチャートである。
【図７】アロケーションエクステントの長さを選択する画面の例である。
【図８】ボリウムストラクチャディスクリプタを説明する図である。
【図９】メディアインフォメーションディスクリプタを説明する図である。
【図１０】ドライブインフォメーションディスクリプタを説明する図である。
【図１１】エクステンデッドデータディスクリプタを説明する図である。
【図１２】ファイルシステムを説明する図である。
【図１３】チャイルドリンク、ネクストリンク、およびペアレントリンクを説明する図である。
【図１４】ファイルテーブルを説明する図である。
【図１５】ファイルテーブルストラクチャタイプ0のファイルテーブルを説明する図である。
【図１６】アロケーションエクステントテーブルを説明する図である。
【図１７】アロケーションストラテジィテーブルを説明する図である。
【図１８】エクステンデッドアトリビュートテーブルを説明する図である。
【図１９】本発明の記録再生装置１の一実施の形態の構成を示すブロック図である。
【図２０】再生のときの、バッファ１７に記録されているデータの量とバッファ１７に書き込まれるデータの速度の関係を示す図である。
【図２１】光ディスク８に記録されているファイルの構成を説明する図である。
【図２２】ファイルの構成とバッファ１７に記憶されたデータの量を示す図である。
【図２３】光ディスク８に記録されているファイルの他の構成を説明する図である。
【図２４】図２３の場合のファイルの構成とバッファ１７に記憶されているデータの量を示す図である。
【図２５】ファイルのブロックへの記録の処理を説明する図である。
【図２６】ブロックへのデータの記録の処理を説明するフローチャートである。
【図２７】ブロックへの記録されたファイルの分割の処理を説明する図である。
【図２８】ブロックへの記録されたファイルの分割の他の処理を説明する図である。
【図２９】ブロックへの記録されたファイルの分割のさらに異なる処理を説明する図である。
【図３０】ファイルの分割の処理を説明するフローチャートである。
【図３１】ファイルの分割の処理を説明するフローチャートである。
【図３２】ファイルの分割の処理を説明するフローチャートである。
【図３３】ブロックの空き領域の圧縮の処理を説明する図である。
【図３４】ブロックの空きの圧縮の処理を説明するフローチャートである。
【符号の説明】
１ 記録再生装置， ２ ユーザ入出力部， ３ AV入出力部， ４ PCデータ入出力部， ５ システムコントロール部， ６ ファイル管理部， ７ ドライブ部， ８ 光ディスク， ３１乃至３４，５１乃至５４，７１乃至７４，９１乃至９３，１０１，１１１乃至１１４，１２１乃至１２３，１３１，１４１乃至１４３ ブロック
【発明の属する技術分野】
本発明は、記録再生装置、ファイル管理方法、並びに提供媒体に関し、特に、デイスク状記録媒体を使用する記録再生装置（VDR: Video Disc Recorder）に使用するファイルシステムに関する。
【０００２】
【従来の技術】
デイスク状記録媒体にデータを記録するためのファイルシステムとしては、ISO/IEC13346:1995, "Information technology - Volume and file structure of write-once and rewritable media using non-sequential recording for information interchange."が知られている。このファイルシステムは、各種データを記録するための汎用的なファイルシステムであり、個人が家庭内でデイスクに圧縮されたデジタルAV（音声、ビデオ）信号を記録するためのものでは無い。従って、圧縮されたデジタルAV（音声、ビデオ）信号を記録するには必ずしも十分なものではない。従って、AV信号を記録するに最適なファイルシステム、及びボリウムが求められている。
【０００３】
【発明が解決しようとする課題】
従って、個人が家庭内で簡単にデイスクにAV信号を記録再生するためのファイルシステムが必要である。
【０００４】
【課題を解決するための手段】
請求項１に記載の記録再生装置は、AVデータのファイルを記録する第１の記録手段と、ディスク状記録媒体に対して記録可能な情報の単位の長さを設定する設定手段と、ファイルに対応して、設定手段により設定された長さの単位のうち、そのファイルを記録するとき採用された単位の長さを識別する識別情報を含む、ファイルの管理情報を、論理ボリウムの少なくとも２個所に記録する第２の記録手段とを備えることを特徴とする。
【０００５】
請求項３に記載のファイル管理方法は、AVデータのファイルを記録する第１の記録ステップと、ディスク状記録媒体に対して記録可能な情報の単位の長さを設定する設定ステップと、ファイルに対応して、設定ステップの処理により設定された長さの単位のうち、そのファイルを記録するとき採用された単位の長さを識別する識別情報を含む、ファイルの管理情報を、論理ボリウムの少なくとも２個所に記録する第２の記録ステップとを含むことを特徴とする。
【０００６】
請求項４に記載の提供媒体は、AVデータのファイルを記録する第１の記録ステップと、ディスク状記録媒体に対して記録可能な情報の単位の長さを設定する設定ステップと、ファイルに対応して、設定ステップの処理により設定された長さの単位のうち、そのファイルを記録するとき採用された単位の長さを識別する識別情報を含む、ファイルの管理情報を、論理ボリウムの少なくとも２個所に記録する第２の記録ステップとを含む処理を実行させるコンピュータが読みとり可能なプログラムを提供することを特徴とする。
【００１０】
請求項１に記載の記録再生装置、請求項３に記載のファイル管理方法、および請求項４に記載の提供媒体においては、AVデータのファイルを記録し、ディスク状記録媒体に対して記録可能な情報の単位の長さを設定し、ファイルに対応して、設定された長さの単位のうち、そのファイルを記録するとき採用された単位の長さを識別する識別情報を含む、ファイルの管理情報を、論理ボリウムの少なくとも２個所に記録する。
【００１６】
【発明の実施の形態】
はじめに、ディスク状記録媒体のフォーマット方式について説明する。図１は、ディスク状記録媒体全体のフォーマットを説明する図である。ディスクは、長さが可変長の複数のアロケーションエクステントに分割される。アロケーションエクステントは、長さが固定の複数のブロックから構成される。ブロックは、所定の数の物理セクタから構成される。
【００１７】
図２は、アンカーディスクリプタについて説明する図である。ディスク内に、４つのアンカーディスクリプタが配置される。アンカーディスクリプタには、ボリウム管理用マネージメントインフォメーションエリアの位置が記録されている。ボリウム管理用マネージメントインフォメーションエリアのボリウムストラクチャディスクリプタには、フィジカルボリウムインフォメーション、パーテーションインフォメーション、ロジカルボリウムインフォメーション、およびパーテーションマップが含まれている。
【００１８】
ボリウムストラクチャディスクリプタには、ユーザエリアとしてのロジカルボリウムが記述されている。図３は、ロジカルボリウムを説明する図である。ロジカルボリウムには、ファイルシステムディスクリプタが、配置されている。ロジカルボリウムの先頭付近、および終了付近には、それぞれ、MIA(Management Information Area)が配置されている。MIAには、ファイルテーブル、アロケーションエクステントテーブル、アロケーションストラテジィテーブル、ディフェクトインフォメーションテーブル、エクステンデッドアトリビュートテーブルが含まれている。アロケーションエクステントの長さは、アロケーションストラテジィテーブルを構成するアロケーションストラテジィレコードに記述される。
【００１９】
ユーザは、ディスクにファイルのデータを記録する前に、そのディスクに記録するデータのアロケーションエクステントの長さを予め設定する。これにより、例えば、AVデータは、より長い長さのアロケーションエクステントのフォーマットで記録し、PCデータは短い長さのアロケーションエクステントのフォーマットで記録することが可能となる。AVデータは連続するデータであることが多いので、アロケーションエクステントの長さを長くした方が、データをより効率的に記録再生することができる。
【００２０】
図４は、アロケーションエクステントの長さの設定の処理を説明するフローチャートである。ステップＳ１１において、後述するドライブ部７は、ユーザからの設定入力に対応して、MIAに含まれるアロケーションストラテジィテーブルに、アロケーションエクステントの設定された長さに対応したアロケーションストラテジィレコードを書き込む。アロケーションストラテジィテーブルには、複数のアロケーションストラテジィレコードを書き込むことができる。図５は、アロケーションエクステントの長さをユーザが設定する画面の例を示す図である。アロケーションエクステントの長さとしては、4MByte以上，64KByte，2kByteなど任意の長さが設定可能であり、かつ、複数の長さの設定が可能である。そのディスクには、予め設定した長さのアロケーションエクステントのフォーマットの中から指定されたものでのみ記録が可能である。
【００２１】
このように、アロケーションエクステントの長さを設定し、ディスクに記録した後、そのディスクにデータを記録する場合の処理は、図６のフローチャートに示すようになる。ステップＳ２１において、ユーザは、これから記録するデータのアロケーションエクステントの長さを選択する。図７は、アロケーションエクステントの長さを選択する画面の例を表している。この長さとしては、そのディスクに予め設定された値だけが表示される。画面のボタンを操作することで、ボタンに対応するアロケーションエクステントの長さが、選択される。AVデータを記録するとき、PCデータを記録するときに較べて、より長いアロケーションエクステントを指定することで、より効率的なデータの記録が可能になる。アロケーションエクステントの長さの指定により、アロケーションストラテジィテーブル内に配置されたアロケーションストラテジィレコードが指定される。指定が完了すると、ステップＳ２２において、ドライブ部７は、入力されたデータをディスクに記録する。データの記録が完了すると、ステップＳ２３において、ドライブ部７は、ディスクにそのファイルのアロケーションエクステントの長さに対応した番号を記録する。後述するファイル管理部６は、アロケーションエクステントの長さに対応した番号を知ることにより、対応するアロケーションストラテジィレコードの内容を利用することができる。
【００２２】
後述する図１９のシステムコントロール部５が、ＡＶデータを記録しようとしているのか、ＰＣデータを記録しようとしているのかを判断することができる場合には、前述のステップＳ２１をユーザからの入力なしに行うことも可能である。
【００２３】
以上のように、ディスクにファイルが記録される。
【００２４】
ボリウムの構成について説明する。ディスクエクステント(DescExtent)は、後述のMIA内に記録されたディスクリプタ（descriptor）中の後述するMIB(Management Information Block)にアライメントされた領域を表現するのに用いられる。ディスクエクステントは表１に示す様式で記録する。
【００２５】
【表１】
オフセットフロムトップオブディスクリプタ(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エントリは表２に示す様式で記録する。
【００２８】
【表２】
フィジカルセクタナンバオブディフェクトセクタ(Physical Sector Number of Defect Sector :RBP 0)はスリッピングを行う物理セクタの物理セクタ番号を指定する。
【００３０】
SDLエントリ(Secondary Defect List Entry)は、ディフェクトマネージメントにおいてリニアリプレースメント行う物理セクタの物理セクタ番号とその代替として使用する物理セクタの物理セクタ番号を記録するのに用いる。SDLエントリは表３に示す様式で記録する。
【００３１】
【表３】
表３のフィジカルセクタナンバオブディフェクトセクタはリニアリプレースメントを行う物理セクタの物理セクタ番号を指定する。フィジカルセクタナンバオブスペアセクタ(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が最後についた数値は、１６進数を表す）をアンカーポイントとする。パーシャル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）の大きさは物理セクタサイズ以下で、表４に示す様式で記録される。
【００４９】
【表４】
シグニチャ（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マップは表５に示す様式で記録する。
【００５３】
【表５】
シグネチャ(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に対応する。表６は、マップエントリの値を示す表である。
【００５６】
【表６】
図８は、ボリウムストラクチャディスクリプタ（Volume Structure Descriptor）の構造を示す図である。ここで、@APSは、アライントゥフィジカルセクタ(Align to Physical Sector)を示し、そのデータは、物理セクタにアライメントすることを示す。また、アライメントに際し、直前に記録すべきデータが実際に記録された場所の次のバイトからそのセクタの終りまでの領域は、#00が設定される。
【００５８】
ボリウムストラクチャヘッダ（Volume Structure Descriptor Header）は、表７に従って記録される。
【００５９】
【表７】
シグネチャ(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）は表８に従って記録しなければならない。
【００６２】
【表８】
キャラクタセット(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）は、表９で示す様式で記録しなければならない。
【００６６】
【表９】
スタートフィジカルセクタナンバ(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)は、このパーティションの記録特性の状態を指定する。表１０は、アクセスタイプの内容を示す表である。
【００６８】
【表１０】
ユーゼジインフォメーション(Usage Information:RBP 17)は、このパーティションの利用状態を指定する。表１１は、ユーゼジインフォメーションの内容を示す表である。
【００７０】
【表１１】
リザーブド(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）は、表１２に示す様式で記録する。
【００７３】
【表１２】
スタートフィジカルセクタナンバ(Start Physical Sector Number:RBP 0)は、スペアエリアの先頭の物理セクタの物理セクタ番号を指定する。ナンバオブフィジカルセクタ(Number of Physical Sector:RBP 4) は、スペアを構成する物理セクタの数を指定する。リザーブド(Reserved:RBP 8)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
【００７５】
論理ボリウムインフォメーションヘッダ（Logical Volume Information Header）は、表１３で示す様式で記録される。
【００７６】
【表１３】
キャラクタセット(Charactor Set:RBP 0)は、論理ボリウムネームフィールドに記録された論理ボリウムの名前の文字コードを指定する。ロジカルボリュームネームサイズ(Logical Volume Name Size:RBP 2)は、論理ボリウムネームフィールドに指定された論理ボリウムの名前の大きさ(バイト数)を指定する。ロジカルボリュームネーム(Logical Volume Name:RBP 4)は、論理ボリウムの名前を指定する。ブートインジケータ(Boot Indicator:RBP 260)は、論理ボリウムからの起動に関する情報を指定する。ブートインジケータの内容を表１４に示す。ブートインジケータがアクティブであり、かつ、その先頭パーティションがその物理ボリウムにある論理ボリウムは、物理ボリウム中に2つ以上あってはならない。
【００７８】
【表１４】
ファイルシステムインジケータ(File System Indicator:RBP 262)は、この論理ボリウムで使用されているファイルシステムを指定する。ファイルシステムインジケータの内容を表１５に示す。
【００８０】
【表１５】
ロジカルセクタサイズ(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）は表１６に示す様式で記録される。
【００８３】
【表１６】
ボリュームアイデンティファイア(Volume Identifier:RBP 0)は、論理ボリウムを構成するパーティションが属している物理ボリウムの物理ボリウムインフォメーションに記録された物理ボリウム識別子を指定する。パーテーションナンバ(Partition Number:RBP 20)は、論理ボリウムを構成するパーティションのパーティション番号を指定する。リザーブド(Reserved:RBP 22)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
【００８５】
ディフェクトリストインフォメーションヘッダ（Defect List Information Header）は表１７に示す様式で記録される。
【００８６】
【表１７】
ナンバオブ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）は表１８に示す様式で記録される。
【００８９】
【表１８】
シグネチャ(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）の構造を図９に示す。
【００９２】
メディアインフォメーションディスクリプタヘッダ（Media Information Descriptor Header）は、表１９に示す様式で記録される。
【００９３】
【表１９】
シグネチャ(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）は、表２０に示す様式で記録される。
【００９６】
【表２０】
スタートフィジカルセクタナンバ(Start Physical Sector Number:RBP 0)は、ゾーンの先頭の物理セクタの物理セクタ番号を指定する。ナンバオブフィジカルセクタ(Number of Physical Sector:RBP 4)は、ゾーンを構成する物理セクタの数を指定する。リザーブド(Reserved:RBP 8)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
【００９８】
ドライブインフォメーションディスクリプタ（Drive Information Descriptor）の構造を図１０に示す。
【００９９】
ドライブインフォメーションディスクリプタヘッダ（Drive Information Descriptor Header）は、表２１に示す様式で記録される。
【０１００】
【表２１】
シグネチャ(Signature:BP 0)のデータタイプフィールドは、21が設定される。ディスクリプタサイズ(Descriptor Size:BP 8)は、ドライブインフォメーションディスクリプタの大きさ(MIB数)を指定する。ストラテジィタイプ(Strategy Type:BP 10)は、ストラテジィタイプを指定する。リザーブド(Reserved:BP 11)は、将来の拡張の為に予約され、全てのバイトに#00を設定する。
【０１０２】
エクステンデッドデータディスクリプタ（Extended Data Descriptor）の構造を図１１に示す。ここで、@APSは、アライントゥフィジカルセクタ(Align to Physical Sector)を示し、そのデータは物理セクタにアライメントしなければならないことを示す。また、直前のデータの次のバイトからそのセクタの終りまでの領域は、#00が設定される。
【０１０３】
エクステンデッドデータディスクリプタヘッダ（Extended Data Descriptor Header）は、表２２に示す様式で記録される。
【０１０４】
【表２２】
シグネチャ(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）について説明する。表２３は、VDRの場合のFAT, ISO9660(with Joliet), ISO/IEC13346, KIFSのハイブリッドディスクのボリューム構造の例を示す表である。表２３の◆は再配置不可能な位置固定情報であることを示す。
【０１０９】
【表２３】
次に論理ボリウム上に構成される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)フィールドに表２４に示すように設定される。
【０１１３】
【表２４】
メイン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では、ファイルテーブルの最初のファイルレコードがルートとなる図１２に示されるような木構造が構築される。図中の円は、一つのファイルレコードを表しており、ルートのファイルレコードはルートファイルレコード（Root File Record）と称される。参照すべきデータを持たないファイルレコードは、ディレクトリと称され、データを持つファイルレコードはファイルと称される。ディレクトリばかりでなく、ファイルも子ファイルレコードを有することが出来る。この階層構造は、図１３に示されるようにチャイルドリンク（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)が設定される。シグネチャは表２５に示すように記録される。
【０１２８】
【表２５】
アイデンティフィケーション(Identification:RBP 0)は、文字列"AVFS"がISO/IEC 646に従って設定される。バージョン(Version:RBP 4)は、バージョン番号を指定し、1が設定される。データタイプ(Data type:RBP 5)は、データ構造体の種類を指定する。データ構造体の種類により、表２６に示される値が設定される。
【０１３０】
【表２６】
リザーブド(Reserved:RBP 6)は、拡張のために予約され、#00が設定される。シグネチャは、クラッシュリカバリのときデータ構造体を識別する為に使われる。
【０１３２】
AVファイルシステムディスクリプタ（AV File System Descriptor）は、表２７に示すように記録される。
【０１３３】
【表２７】
シグネチャのデータタイプフィールドは、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マップは、表２８に示すように記録される。
【０１３７】
【表２８】
シグネチャ(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...に対応する。
【０１４１】
マップエントリの値は、表２９に示す意味を有する。
【０１４２】
【表２９】
もしデータ構造体が論理セクタサイズに等しいかあるいは小さく、1つのMIB内に格納される場合、そのMIBに対応するマップエントリに#FFFFが、セットされる。データ構造体が複数のMIBにわたって記録される場合、最後以外のMIBに対応するマップエントリには次のMIBのMIB番号が、最後のMIBに対応するマップエントリには#FFFFがセットされる。マップエントリの値が#FFF1であるMIBは、そのブロックが未使用である事を示し、データ構造体が新しいMIBを必要とする場合に使用する事が出来る。マップエントリの値が#FFF0であるMIBは、その使用に問題がある(欠陥セクタなど)ことを表す。
【０１４４】
ファイルテーブル（File Table）は図１４に示すようにファイルテーブルヘッダとファイルテーブルデータから構成される。ファイルテーブルデータの構造はファイルテーブルヘッダのFile Table Structure Typeフィールドによって決まる。
【０１４５】
ファイルテーブルヘッダ（File Table Header）は、表３０に示すように記録される。
【０１４６】
【表３０】
シグネチャ(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の場合、ファイルテーブルは図１５に示すようにファイルテーブルヘッダと1個以上のファイルレコードから構成される。ファイルレコードは、0から始まる連続、昇順の番号が付され、この番号は、ファイルレコード番号と称される。ファイルレコードのリストは次のレコードのファイルレコード番号をネクストリンク（Next Link）フィールドに設定する事により作られ、このリストはファイルレコードチェインと称される。ファイルテーブル内の使用されてないすべてのファイルレコードは、フリーファイルレコードチェインと称されるファイルレコードチェインを作成する。
【０１４９】
ファイルテーブルストラクチャタイプが0の場合、ファイルテーブルヘッダ（File Table Header）は表３１に示すように記録されなければならない。
【０１５０】
【表３１】
シグネチャ(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）は、表３２に示すように記録されなければならない。
【０１５３】
【表３２】
ファイル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）フィールドは、表３３に示すように記録される。
【０１５７】
【表３３】
バリッド(Valid:Bit 0)は、このファイルレコードが有効なレコードであるかどうかを表し、0の場合、このファイルレコードが使われていないことを表し、ファイルレコードは、フリーファイルレコードチェイン中にある。バリッドが、1の場合、このファイルレコードが使用されていることを表し、ルートファイルレコードからチャイルドリンク, ネックストリンクを経て到達する事ができる。データロケーションタイプ(Data Location Type:Bit 0-1)は、データロケーション(Data Location:RBP 24)のフォーマットを指定する。データロケーションタイプが00の場合、データロケーションは参照するものがない事を示す(ファイルレコードがディレクトリの場合は、この値をセットする)。データロケーションタイプが01の場合、データロケーションは、アロケーションエクステントレコードチェインの先頭のアロケーションエクステントレコード番号とアロケーションストラテジィ番号を表３４に示すフォーマットで表される。データロケーションタイプが10の場合、ファイルレコードはサブファイルであることを表し、データロケーションは、ペアレントファイルレコードのデータロケーションが表すデータの先頭からのオフセットがUint64で表される。11のデータロケーションタイプは、拡張のために予約されている。
【０１５９】
【表３４】
プロテクテッド(Protected:Bit 3)は、このファイルレコードがプロテクトされていることを表す。ソーテッド(Sorted:Bit 4)は、このファイルレコードの属するファイルレコードチェインがファイルタイプの若い順にソートされ、さらに同じファイルタイプの中ではファイルIDの若い順にソートされている事を表す。リザーブド(Reserved:Bit 5-31)は、拡張のために予約されている。
【０１６１】
アロケーションエクステントテーブル（Structure of the Allocation Extents Table）は、図１６に示すようにアロケーションエクステントテーブルヘッダとアロケーションエクステントレコードから構成される。アロケーションエクステントレコードには0から始まる連続、昇順の番号が付される。この番号は、アロケーションエクステントレコード番号と称される。次のレコードのアロケーションエクステントレコード番号をネクストアロケーションエクステントレコードフィールドに設定する事により、アロケーションエクステントレコードのリストはつくられる。このリストはアロケーションエクステントレコードチェインと称される。
【０１６２】
アロケーションエクステントテーブルヘッダ（Allocation Extents Table Header）は、表３５に示すように記録される。
【０１６３】
【表３５】
シグネチャ(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）は、アロケーションエクステントの開始位置、終了位置、属性、アロケーションエクステントレコードチェインを構成する次のアロケーションエクステントレコードの位置を表す。アロケーションエクステントレコードは、表３６に示すように記録される。
【０１６７】
【表３６】
スタートロジカルセクタナンバ(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)の表す値は、表３７に示す意味を有する。
【０１７０】
【表３７】
アロケーションエクステントレコードステータス (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ファイルシステムがこの論理ボリウムでデータを配置するのに使用しているすべてのアロケーションストラテジィを指定する。アロケーションストラテジィテーブルは図１７に示すようにアロケーションストラテジィテーブルヘッダとアロケーションストラテジィレコードから構成される。
【０１７４】
アロケーションストラテジィテーブルヘッダ（Allocation Strategy Table Header）は、表３８に示すように記録される。
【０１７５】
【表３８】
シグネチャ(Signature:BP 0)のデータタイプフィールドは、5が設定される。ナンバオブアロケーションストラテジィレコード(Number of Allocation Strategy Record:BP 8)は、アロケーションストラテジィ テーブル中のアロケーションストラテジィレコードの数を指定する。リザーブド(Reserved:RBP 10)は、拡張のために予約され、#00が設定される。
【０１７７】
アロケーションストラテジィレコードは、アロケーションストラテジィを指定するのに使用される。アロケーションストラテジィレコードは、表３９に示すように記録される。
【０１７８】
【表３９】
レングスオブアロケーションストラテジィレコード(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においては、次の条件を満足する。第１に、アロケーションエクステントは、アロケーションストラテジィレコードのスタートロジカルセクタナンバ(Start Logical Sector Number:RBP 8)およびエンドロジカルセクタナンバ(End Logical Sector Number:RBP 12)で指定された領域内に配置されなければならない。第２に、論理セクタの一部が、あるアロケーションエクステントに割り当てられている場合、その論理セクタのどのバイトも別のアロケーションエクステントに属さない。第３に、アロケーションエクステントの先頭と論理セクタの先頭は一致する。アロケーションストラテジィタイプ 0のアロケーションストラテジィレコードは、表４０に示すように記録される。
【０１８１】
【表４０】
レングスオブアロケーションストラテジィレコード(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のアロケーションストラテジィレコードは、表４１に示すように記録される。
【０１８４】
【表４１】
レングスオブアロケーションストラテジィレコード(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)で指定された数のゾーンインフォメーションレコードが設定される。ゾーンインフォメーションレコードは、表４２に示すように記録される。
【０１８６】
【表４２】
スタートロジカルセクタナンバ(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）は論理ボリウム中の欠陥セクタの論理セクタ番号を記録する。ディフェクトインフォメーションテーブルは、表４３に示すように記録される。
【０１８９】
【表４３】
シグネチャ(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）は、図１８に示すようにエクステンデッドアトリビュートテーブルヘッダとエクステンデッドアトリビュートレコードから構成される。エクステンデッドアトリビュートテーブル中のエクステンデッドアトリビュートレコードは、0から始まる連続、昇順の番号が付され、この番号は、エクステンデッドアトリビュートレコード番号と称される。エクステンデッドアトリビュートレコードのリストは、ネクストエクステンデッドアトリビュートレコードフィールドに次のレコードを設定する事により作成され、このリストは、エクステンデッドアトリビュートレコードチェインと称される。エクステンデッドアトリビュートテーブル内の使用されてないエクステンデッドアトリビュートレコードは、フリーエクステンデッドアトリビュートレコードチェインと呼ばれるリストを作成する。
【０１９２】
エクステンデッドアトリビュートテーブルヘッダ（Extended Attribute Table Header）は、表４４に示すように記録される。
【０１９３】
【表４４】
シグネチャ(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）は、表４５に示すように記録される。
【０１９６】
【表４５】
ネクストエクステンデッドアトリビュートレコード(Next Extended Attribute Record:RBP 0)は、エクステンデッドアトリビュートレコードチェインを構成する次のエクステンデッドアトリビュートレコード番号を指定し、このエクステンデッドアトリビュートレコードが最後のエクステンデッドアトリビュートレコードである場合、#FFFFがセットされる。
【０１９８】
既存のファイルシステムの多くはメディアの欠陥セクタ処理をファイルシステムの下に位置するレイヤ(例えばドライブ内部の交替処理)で行う事を前提に設計されている。これらのファイルシステムでは欠陥セクタがどこにあるのかが分からず、欠陥がない部分ではドライブの生の転送速度でデータにアクセスできるが、交替処理が行われている部分ではそれよりもはるかに低い転送速度でしかアクセスが出来ない。
【０１９９】
従来のコンピュータ用途では平均アクセス時間の向上が要求される事はあっても個々のアクセス時間の見積もりが要求される事はなかったため上記のような構成でも問題はなかった。しかし、オーディオ, ビデオ用途ではデータを一定時間内に一定量供給できなければ音声や映像を正しく記録再生する事ができないため、ファイルシステムがデータアクセスにかかる時間の見積もりを行える事が必要となってきた。
【０２００】
そこで本ファイルシステムでは欠陥セクタ処理を下のレイヤで行わなくても良いという前提を導入し、ファイルシステムがデータのアクセスにかかる時間を正確に見積もる事が出来るようにした。これに伴い、本ファイルシステムでは従来のファイルシステムにはなかった欠陥セクタ処理の為のフィールドやフラグが用意され、これを使って欠陥セクタの処理が行う事が出来る。ここでは本ファイルシステムに用意された機能を使って欠陥セクタ処理を行う方法の一例を解説する。
【０２０１】
一般に欠陥セクタが検出されるのは次のいずれかである。第１に、書き込み中にエラーが発生し欠陥セクタが検出される。第２に、書き込みは正常終了したが、書き込み直後にその部分を読み出した際にエラーが検出される。第３に、書き込み、および書き込み直後の読み出しは正常終了したが、時間を経て読み出しを行った時にエラーが検出される。
【０２０２】
第１および第２の場合は、書き込み直後に読み出しを行い、正しく書き込めた事を確認する(Write and Verify)操作を行うことにより書き込み時に検出、対応できる。
【０２０３】
第３の場合は、光ディスクにおけるごみ、傷による障害などで発生するケースである。このケースについては完全な対応策は存在しないが、多重書きを行う事により、データロスの可能性を著しく下げる事が出来る。本ファイルシステムは、主にこのWrite and Verifyと多重書きの２つの手法を使って欠陥セクタの処理を行う。
【０２０４】
ボリウム構造は、ボリウムストラクチャディスクリプタ(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のアロケーションエクステントとして、ディフェクティブアロケーションエクステントレコードチェインに登録される。
【０２１１】
図１９は、本発明の記録再生装置１の一実施の形態の構成を示すブロック図である。記録再生装置１は、光ディスク８が装着され、光ディスク８に外部から供給されたビデオ信号およびオーディオ信号並びにPC(Personal Computer)データを記録するか、または、光ディスク８に記録されている信号を読み取り、外部に出力する。
【０２１２】
ユーザ入出力部２は、キーパネル１１およびLCD(Liquid Crystal Display)１２を有する。キーパネル１１は、ユーザの操作に応じた信号を発生し、システムコントロール部５に供給するようになされている。LCD１２は、システムコントロール部５から供給された信号に基づき、記録再生装置１の状態または記録再生装置１に装着された光ディスク８に関する情報等を表示する。
【０２１３】
AV入出力部３は、エンコーダ/デコーダ１３および１４並びにマルチプレクサ/デマルチプレクサ１５を有し、システムコントロール部５から供給された信号に基づき、エンコーダ/デコーダ１３および１４並びにマルチプレクサ/デマルチプレクサ１５を制御する。また、AV入出力部３は、システムコントロール部５にエンコーダ/デコーダ１３および１４並びにマルチプレクサ/デマルチプレクサ１５の状態を示す信号を供給する。
【０２１４】
エンコーダ/デコーダ１３は、記録時において、外部から供給されたビデオ信号を圧縮（エンコード）して、ビデオ信号に対応する所定の方式のビデオデータをマルチプレクサ/デマルチプレクサ１５に出力し、再生時において、マルチプレクサ/デマルチプレクサ１５から供給された所定の方式のビデオデータを伸張（デコード）して外部に出力する。エンコーダ/デコーダ１４は、記録時において、外部から供給されたオーディオ信号を圧縮（エンコード）して、オーディオ信号に対応する所定の方式のオーディオデータをマルチプレクサ/デマルチプレクサ１５に出力し、再生時において、マルチプレクサ/デマルチプレクサ１５から供給された所定の方式のオーディオデータをを伸張（デコード）して外部に出力する。
【０２１５】
マルチプレクサ/デマルチプレクサ１５は、記録時において、エンコーダ/デコーダ１３および１４から供給された所定の方式のビデオデータおよびオーディオデータを多重化し、ドライブ部７に出力するようになされている。また、再生時において、ドライブ部７から供給された多重化されたビデオデータおよびオーディオデータを分離し、ビデオデータをエンコーダ/デコーダ１３に、オーディオデータをエンコーダ/デコーダ１４に出力するようになされている。
【０２１６】
PCデータ入出力部４は、インターフェース１６を有し、システムコントロール部５から供給された信号に基づき、インターフェース１６を制御し、システムコントロール部５にインターフェース１６の状態を示す信号を出力する。インターフェース１６は、外部のパーソナルコンピュータ（図示せず）等から供給された所定の形式のPCデータを入力し、ドライブ部７が読み取り可能なデータに変更し、ドライブ部７に出力する。インターフェース１６は、また、ドライブ部７から供給されたデータを所定の形式で、外部のパーソナルコンピュータ等に出力するようになされている。
【０２１７】
システムコントロール部５は、ユーザ入出力部２、AV入出力部３、PCデータ入出力部４、およびファイル管理部６それぞれの状態に基づき、ユーザ入出力部２、AV入出力部３、PCデータ入出力部４、およびファイル管理部６を制御するようになされている。
【０２１８】
ファイル管理部６は、システムコントロール部５からの信号に基づき、ドライブ部７を制御し、ドライブ部７の状態に応じた信号をシステムコントロール部５に供給するようになされている。
【０２１９】
ドライブ部７は、バッファ１７、ECC回路１８、変調/復調回路１９、およびピックアップ２０を有し、ファイル管理部６からの信号に基づき、バッファ１７、ECC回路１８、変調/復調回路１９、およびピックアップ２０を動作させ、光ディスク８に信号を記録し、または光ディスク８から信号を読み出すようになされている。
【０２２０】
バッファ１７は、AV入出力部３またはPCデータ入出力部４から供給されたデータを一時的に記憶し、データが途切れないように、ECC(Error Correction Code)回路１８にデータを出力し、また、ECC回路１８から供給されたデータを一時的に記憶し、データが途切れないように、AV入出力部３またはPCデータ入出力部４に供給するようになされている。
【０２２１】
ECC回路１８は、バッファ１７から供給されたデータにECCを付加して、変調/復調回路１９に出力し、また、変調/復調回路１９から供給されたデータを、ECCを基に誤り訂正した後、バッファ１７に出力するようになされている。
【０２２２】
変調/復調回路１９は、ECC回路１８から供給されたデータを所定の方式に変調してピックアップ２０に出力し、ピックアップ２０から供給されたデータを所定の方式に基づいて復調し、ECC回路１８に出力するようになされている。
【０２２３】
ピックアップ２０は、変調/復調回路１９から供給されたデータに基づき、記録再生装置１に装着された光ディスク８にデータを記録し、または光ディスク８に記録されたデータを読み取り、変調/復調回路１９に出力するようになされている。
【０２２４】
図２０は、再生のときの、バッファ１７に記録されているデータの量とバッファ１７に書き込まれるデータの速度の関係を示す図である。バッファ１７から出力されるデータの読み出し速度Routは、エンコーダ/デコーダ１３および１４が信号の出力を途切れさせないようにするため、所定の値以上の一定値となるように制御される。バッファ１７に供給されるデータのデータ書き込み速度は、光ディスク８の所定のファイルが記録されているセクタを読み取っているとき、図２０（Ｂ）に示すように、一定の値Rinになる。一方、データ書き込み速度は、ピックアップ２０が光ディスク８のトラックの間を移動しているとき、または所定のセクタがピックアップ２０の読み取り可能な位置に来るまで光ディスク８の回転を待っているとき（図２０（Ｂ）の時間Tsの間）、0になる。
【０２２５】
このため、バッファ１７へのデータ書き込み速度が0になるとき、バッファ１７に記録されているデータの量は、読み出し速度Routで読み出しされるだけとなるため、図２０（Ａ）に示されるように、急激に減少する。バッファ１７の記憶可能なデータ量は、所定の期間、データ書き込みが無くとも、データの読み出しが途切れないように、Rin、およびデータの読み出し速度により決定される。
【０２２６】
図２１は、光ディスク８に記録されているファイルの構成を説明する図である。ブロックは、ディスク全体を等しい大きさに分割したもので、ブロック内が物理的に連続で、かつ、ブロック内ではRinの速度でデータの転送が実行される。ファイルのデータは、１または複数のブロックに記録される。従って、ブロックは、ファイルの一部または全部のデータが記録されているブロック、またはファイルのデータが記録されていないブロックにわかれる。ブロックに記録されているファイルのデータ量がブロックの大きさより小さいとき、そのファイルの直前のブロックは、その全てにデータが記録されている。
【０２２７】
図２２は、ファイルの構成とバッファ１７に記憶されたデータの量を示す図である。図２２（Ａ）は、ブロックに記録されているファイルを説明する図である。ブロック３１は、その全てにファイルのデータが記録されている。ブロック３１に連続するブロック３２は、その一部にファイルのデータが記録されている。ブロック３３は、その全てにファイルのデータが記録されている。ブロック３３に連続するブロック３４は、その一部にファイルのデータが記録されている。
【０２２８】
図２２（Ｂ）は、図２２（Ａ）に示されたブロックを読み出すときのバッファ１７への書き込み速度を表す図である。ブロック３１を読み出すとき、バッファ１７への書き込み速度は、ブロック３１が物理的に連続しているため、Rinの一定速度となる。同様に、ブロック３２を読み出すとき、ブロック３３を読み出すとき、およびブロック３４を読み出すとき、バッファ１７への書き込み速度は、Rinの一定速度となる。
【０２２９】
ブロック３１の読み出しを終了し、つぎにブロック３２の読み出しを行うとき、ブロック３１とブロック３２が物理的に連続しているとは限らないため、連続していなければ、ピックアップ２０は、光ディスク８のトラックの間を移動するか、または所定のセクタがピックアップ２０の読み取り可能な位置に来るまで光ディスク８の回転を待つ。このため、バッファ１７への書き込み速度が0になる期間Ts１が存在する。同様に、ブロック３２の読み出しを終了し、つぎにブロック３３の読み出しを行うとき、バッファ１７への書き込み速度が0になる期間Ts２が存在し、ブロック３３の読み出しを終了し、つぎにブロック３４の読み出しを行うとき、バッファ１７への書き込み速度が0になる期間Ts３が存在する。
【０２３０】
図２２（Ｃ）は、バッファ１７からのデータ読み出し速度を示す図である。データ読み出し速度は、常に一定の値Routである。図２２（Ｄ）は、バッファ１７に記憶されているデータの量を示す図である。図２０（Ａ）に示される場合と同様に、バッファ１７のデータ量は、書き込み速度Rinと読み出し速度Routの差に対応する速度で増加し、バッファ１７へのデータ書き込み速度が0になるとき、バッファ１７に記録されているデータの量は、読み出しだけとなるので、急激に減少する。特に、その一部だけにファイルのデータが記録されているブロック３２およびブロック３４を読み出した後のデータ書き込み速度が0になるとき、バッファ１７に記録されているデータの量は、大きく減少するため、バッファ１７は、アンダフローを防止するには、所定以上の記憶容量が必要となる。
【０２３１】
図２３は、光ディスク８に記録されているファイルの他の構成例を説明する図である。この構成では、その一部または全部にファイルのデータが記録されているブロックは、必ず、ブロックの２分の１以上にファイルのデータが記録されるようになされている。
【０２３２】
図２４は、ファイルが図２３に示すように構成されている場合におけるバッファ１７のデータの量の変化を示す図である。図２４（Ａ）は、ブロックに記録されているファイルを説明する図である。ブロック５１乃至ブロック５４は、前述のように、その２分の１以上にファイルが記録されている。
【０２３３】
図２４（Ｂ）は、図２４（Ａ）に示されたブロックを読み出すときのバッファ１７への書き込み速度を表す図である。ブロック５１を読み出すとき、バッファ１７への書き込み速度は、ブロック５１が物理的に連続しているため、Rinの一定速度となる。同様に、ブロック５２を読み出すとき、ブロック５３を読み出すとき、およびブロック５４を読み出すとき、バッファ１７への書き込み速度は、Rinの一定速度となる。
【０２３４】
ブロック５１の読み出しを終了し、つぎにブロック５２の読み出しを行うとき、ブロックが物理的に離間していれば、バッファ１７への書き込み速度が0になる期間Ts４が存在する。同様に、ブロック５２の読み出しを終了し、つぎにブロック５３の読み出しを行うとき、バッファ１７への書き込み速度が0になる期間Ts５が存在し、ブロック５３の読み出しを終了し、つぎにブロック５４の読み出しを行うとき、バッファ１７への書き込み速度が0になる期間Ts６が存在する。
【０２３５】
図２４（Ｃ）は、バッファ１７からのデータ読み出し速度を示す図である。データ読み出し速度は、常に一定の値Routである。図２４（Ｄ）は、バッファ１７に記憶されているデータの量の変化を示す図である。バッファ１７へのデータ書き込み速度が0になるとき、バッファ１７に記録されているデータの量は、急激に減少する。図２２（Ｄ）の場合と比較し、ブロック５１、ブロック５２、ブロック５３、およびブロック５４は、一定量（1/2）以上のデータを記録しているため、バッファ１７に記録されているデータの量が、０に近づく可能性は、図２２（Ｄ）に示した場合より、少ない。
【０２３６】
図２５は、ファイル管理部６のファイルのブロックへの記録の処理を説明する図である。図２５（Ａ）に示すように、すでにブロック７１乃至７３にファイルのデータが記録されており、新たに、ブロック７４にブロック７４の２分の１より小さいデータ量のファイル７５が記録される場合の処理を説明する。図２５（Ｂ）に示すように、ブロック７３に記憶されたファイルは、ブロック７３の２分の１を占める前半部分８１を残して分割され、後半部分８２がブロック７４の先頭に移動される。ファイル７５は、ブロック７４の後半部分８２に続いて記録される。
【０２３７】
以上のように、ファイルの一部または全部が記録されているブロックは、ブロックの２分の１以上にファイルが記録される。
【０２３８】
以上の処理をまとめると、図２６のフローチャートに示すようになる。すなわち、ステップＳ３１において、ファイル管理部６は、記録するデータ量がブロックの1/2未満であるか否かを判定し、記録するデータ量がブロックの1/2未満であると判定された場合、ステップＳ３２に進み、直前のブロックの後方の1/2のデータを分割し、次のブロックに記録させる。ステップＳ３３において、ファイル管理部６は、そのブロックにブロックの1/2未満の量のデータを記録する。
【０２３９】
ステップＳ３４において、ファイル管理部６は、全てのデータを記録したか否かを判定し、全てのデータを記録していないと判定された場合、ステップＳ３１に戻り、処理を繰り返す。
【０２４０】
ステップＳ３１において、記録するデータ量がブロックの1/2未満でないと判定された場合、ステップＳ３５に進み、ファイル管理部６は、記録するデータ量が１ブロック分以下であるか否かを判定し、記録するデータ量が１ブロック分以下でないと判定された場合、ステップＳ３６に進む。ステップＳ３６において、ファイル管理部６は、１ブロック分のデータを記録し、ステップＳ３４に進む。
【０２４１】
ステップＳ３５において、記録するデータ量が１ブロック分以下であると判定された場合、ステップＳ３７に進み、ファイル管理部６は、そのデータを１ブロックに記録し、ステップＳ３４に進む。
【０２４２】
ステップＳ３４において、全てのデータを記録したと判定された場合、処理は終了する。
【０２４３】
図２７は、ブロックへの記録されたファイルの分割の処理を説明する図である。図２７（Ａ）に示すように、ブロック９１乃至９３に１つのファイルが記録されており、このファイルをブロック９１の始点からブロック９２の分割点（ブロック９２の1/2より前方に位置する）までのファイルと、ブロック９２の分割点からブロック９３の終点までのファイルに分割する場合の処理を説明する。図２７（Ｂ）に示すように、ブロック９２の始点から分割点までの部分９５の前の部分が記憶されたブロック９１のデータは、２分割され、その後半部分９４は、ブロック９２に移動される。ブロック９２に移動された後半部分９４に続いて、ブロック９２の前半部分９５が格納される。一方、ブロック９２の分割点から終点までの部分９６は、新たなブロック１０１に格納される。
【０２４４】
図２８は、ファイルの分割の他の処理例を説明する図である。図２８（Ａ）に示すように、ブロック１１１乃至１１４に記録されている１つのファイルを、ブロック１１２の1/2の位置より前に位置する分割点で分割する場合の処理を説明する。
【０２４５】
図２８（Ｂ）に示すように、ブロック１１１に、ブロック１１２の始点から分割点までの部分１１５を記録できる大きさの領域があれば、ブロック１１１のすでに記録されているファイルに続いて、部分１１５が記録される。ブロック１１２の始点からデータの最後までの部分１１６は、ブロック１１２の始点からの位置に移動される。全ての範囲に記録されたブロック１１３のデータは２分割され、その前半部分１１７は、ブロック１１２に移動され、ブロック１１２の部分１１６に続いて記録される。ブロック１１３の後半部分１１８は、ブロック１１３の始点からの位置に移動される。
【０２４６】
図２９は、ブロックへの記録されたファイルの分割のさらに異なる処理例を説明する図である。図２９（Ａ）に示すように、ブロック１２１乃至１２３に記録されている１つのファイルを、ブロック１２２の中間点を分割点として分割する場合の処理を説明する。図２９（Ｂ）に示すように、ブロック１２２の分割点からデータの最後までの部分１２４は、新たなブロック１３１の先頭に格納される。全ての範囲に記録されたブロック１２３のファイルは２分割され、その前半部分１２５は、ブロック１３１に、部分１２４に続いて格納され、後半部分１２６は、ブロック１２３の先頭に移動される。
【０２４７】
以上のように、ファイルが分割されても、ブロックは、その２分の１以上にファイルが記録される。
【０２４８】
図２７に示された、ブロックの始点から分割点までのデータの大きさがブロックの大きさの1/2未満であり、かつ、分割点から後ろのデータの大きさがブロックの大きさの1/2以上である場合のファイルの分割の処理は、図３０のフローチャートに示すようになる。すなわち、ステップＳ４１において、ファイル管理部６は、分割点のあるブロックの、分割点から後ろのデータを、新たなブロックに移動する。ステップＳ４２において、ファイル管理部６は、分割点のあるブロックの直前のブロックの所定のデータを、分割点のあるブロックの始点からの位置に移動し、分割点のあるブロックの始点から分割点までデータをそのデータの後ろに移動する。
【０２４９】
図２８に示された、分割点のあるブロックの直前の空きの大きさが、分割点のあるブロックの始点から分割点までのデータの大きさ以上であり、かつ、分割点から後ろのデータの大きさがブロックの大きさの1/2未満である場合のファイルの分割の処理は、図３１のフローチャートに示すようになる。ステップＳ５１において、ファイル管理部６は、分割点のあるブロックの、ブロックの始点から分割点までデータを、分割点のあるブロックの直前のブロックの空きに移動する。ステップＳ５２において、ファイル管理部６は、分割点のあるブロックの直後のブロックの所定のデータを、分割点のあるブロックのデータの後ろに移動する。
【０２５０】
図２９に示された、ブロックの始点から分割点までのデータの大きさがブロックの大きさの1/2以上であり、かつ、分割点から後ろのデータの大きさがブロックの大きさの1/2未満である場合のファイルの分割の処理は、図３２のフローチャートに示すようになる。ステップＳ６１において、ファイル管理部６は、分割点から後ろのデータを、新たなブロックに移動する。ステップＳ６２において、ファイル管理部６は、分割点のあるブロックの直後のブロックの所定のデータを、新たなブロックのデータの後ろの位置に移動する。
【０２５１】
以上においては、ブロックの始点から分割点までのデータの大きさがブロックの大きさの1/2以上であるか否かを基準としたが、(n-1)/n(n=2,3,4,5,・・)を基準としてもよい。
【０２５２】
図３３は、連続する３つのブロックの空き領域が、合わせて１ブロック以上ある場合の、ブロックの空き領域の圧縮の処理を説明する図である。図３３（Ａ）に示すように、ブロック１４１乃至１４３の空き領域は、合わせて１ブロック以上ある。ブロック１４２に記憶された内容を、ブロック１４１の空き領域の大きさと同じ大きさの部分１４４と残りの部分１４５に分割する。
【０２５３】
図３３（Ｂ）に示すように、ブロック１４２の部分１４４はブロック１４１の空き領域に移動される。ブロック１４２の部分１４５は、ブロック１４２の先頭に移動され、ブロック１４３のデータ１４６は、ブロック１４２に移動され、部分１４５に続けて格納される。ブロック１４３は、空きになる。
【０２５４】
このように、ブロック１４１乃至１４２の空き領域を少なくし、ブロック１４３を空きにすることができる。
【０２５５】
以上の処理をまとめると、図３４のフローチャートになる。すなわち、ステップＳ７１において、ファイル管理部６は、３つのブロックの空きの合計が、１ブロック以上であるか否かを判定し、３つのブロックの空きの合計が、１ブロック以上であると判定された場合、ステップＳ７２に進み、中間のブロックから、先頭のブロックの空きに、その空きの相当するデータを移動する。ステップＳ７３において、ファイル管理部６は、最後のブロックから、中間のブロックの空きに、その空きの相当するデータを移動し、処理を終了する。
【０２５６】
ステップＳ７１において、３つのブロックの空きの合計が、１ブロック以上でないと判定された場合、処理は終了する。
【０２５７】
以上のように、ファイルの一部または全部が記録されているブロックは、ブロックの２分の１以上にファイルが記録され、書き込み速度が0になる期間が分散されるため、バッファ１７の容量が少なくても出力が途切れない。
【０２５８】
なお、上記したような処理を行うコンピュータプログラムをユーザに提供する提供媒体としては、磁気ディスク、CD-ROM、固体メモリなどの記録媒体の他、ネットワーク、衛星などの通信媒体を利用することができる。
【０２５９】
【発明の効果】
請求項１に記載の記録再生装置、請求項３に記載のファイル管理方法、および請求項４に記載の提供媒体によれば、AVデータのファイルを記録し、ディスク状記録媒体に対して記録可能な情報の単位の長さを設定し、ファイルに対応して、設定された長さの単位のうち、そのファイルを記録するとき採用された単位の長さを識別する識別情報を含む、ファイルの管理情報を、論理ボリウムの少なくとも２個所に記録するようにしたので、個人が家庭内で圧縮ビデオ、圧縮音声信号を簡単に記録再生することができる。
【図面の簡単な説明】
【図１】ディスク状記録媒体全体のフォーマットを説明する図である。
【図２】アンカーディスクリプタについて説明する図である。
【図３】ロジカルボリウムを説明する図である。
【図４】アロケーションエクステントの長さの設定の処理を説明するフローチャートである。
【図５】アロケーションエクステントの長さを設定する画面の例を示す図である。
【図６】ファイルの記録の処理を説明するフローチャートである。
【図７】アロケーションエクステントの長さを選択する画面の例である。
【図８】ボリウムストラクチャディスクリプタを説明する図である。
【図９】メディアインフォメーションディスクリプタを説明する図である。
【図１０】ドライブインフォメーションディスクリプタを説明する図である。
【図１１】エクステンデッドデータディスクリプタを説明する図である。
【図１２】ファイルシステムを説明する図である。
【図１３】チャイルドリンク、ネクストリンク、およびペアレントリンクを説明する図である。
【図１４】ファイルテーブルを説明する図である。
【図１５】ファイルテーブルストラクチャタイプ0のファイルテーブルを説明する図である。
【図１６】アロケーションエクステントテーブルを説明する図である。
【図１７】アロケーションストラテジィテーブルを説明する図である。
【図１８】エクステンデッドアトリビュートテーブルを説明する図である。
【図１９】本発明の記録再生装置１の一実施の形態の構成を示すブロック図である。
【図２０】再生のときの、バッファ１７に記録されているデータの量とバッファ１７に書き込まれるデータの速度の関係を示す図である。
【図２１】光ディスク８に記録されているファイルの構成を説明する図である。
【図２２】ファイルの構成とバッファ１７に記憶されたデータの量を示す図である。
【図２３】光ディスク８に記録されているファイルの他の構成を説明する図である。
【図２４】図２３の場合のファイルの構成とバッファ１７に記憶されているデータの量を示す図である。
【図２５】ファイルのブロックへの記録の処理を説明する図である。
【図２６】ブロックへのデータの記録の処理を説明するフローチャートである。
【図２７】ブロックへの記録されたファイルの分割の処理を説明する図である。
【図２８】ブロックへの記録されたファイルの分割の他の処理を説明する図である。
【図２９】ブロックへの記録されたファイルの分割のさらに異なる処理を説明する図である。
【図３０】ファイルの分割の処理を説明するフローチャートである。
【図３１】ファイルの分割の処理を説明するフローチャートである。
【図３２】ファイルの分割の処理を説明するフローチャートである。
【図３３】ブロックの空き領域の圧縮の処理を説明する図である。
【図３４】ブロックの空きの圧縮の処理を説明するフローチャートである。
【符号の説明】
１ 記録再生装置， ２ ユーザ入出力部， ３ AV入出力部， ４ PCデータ入出力部， ５ システムコントロール部， ６ ファイル管理部， ７ ドライブ部， ８ 光ディスク， ３１乃至３４，５１乃至５４，７１乃至７４，９１乃至９３，１０１，１１１乃至１１４，１２１乃至１２３，１３１，１４１乃至１４３ ブロック
Claims (4)
- ディスク状記録媒体に対してAVデータを記録または再生する記録再生装置において、
AVデータのファイルを記録する第１の記録手段と、
前記ディスク状記録媒体に対して記録可能な情報の単位の長さを設定する設定手段と、
前記ファイルに対応して、前記設定手段により設定された長さの単位のうち、そのファイルを記録するとき採用された前記単位の長さを識別する識別情報を含む、前記ファイルの管理情報を、論理ボリウムの少なくとも２個所に記録する第２の記録手段と
を備えることを特徴とする記録再生装置。 - 前記記録手段に記録される管理情報には、少なくとも、欠陥セクタ、および未使用セクタに関する情報が含まれる
ことを特徴とする請求項１記載の記録再生装置。 - ディスク状記録媒体に対してAVデータを記録または再生する記録再生装置のファイル管理方法において、
AVデータのファイルを記録する第１の記録ステップと、
前記ディスク状記録媒体に対して記録可能な情報の単位の長さを設定する設定ステップと、
前記ファイルに対応して、前記設定ステップの処理により設定された長さの単位のうち、そのファイルを記録するとき採用された前記単位の長さを識別する識別情報を含む、前記ファイルの管理情報を、論理ボリウムの少なくとも２個所に記録する第２の記録ステップと
を含むことを特徴とするファイル管理方法。 - ディスク状記録媒体に対してAVデータを記録または再生する記録再生装置に、
AVデータのファイルを記録する第１の記録ステップと、
前記ディスク状記録媒体に対して記録可能な情報の単位の長さを設定する設定ステップと、
前記ファイルに対応して、前記設定ステップの処理により設定された長さの単位のうち、そのファイルを記録するとき採用された前記単位の長さを識別する識別情報を含む、前記ファイルの管理情報を、論理ボリウムの少なくとも２個所に記録する第２の記録ステップと
を含む処理を実行させるコンピュータが読みとり可能なプログラムを提供することを特徴とする提供媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP22970498A JP4078571B2 (ja) | 1997-10-21 | 1998-08-14 | 記録再生装置、ファイル管理方法、並びに提供媒体 |
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP9-288178 | 1997-10-21 | ||
| JP28817897 | 1997-10-21 | ||
| JP4685598 | 1998-02-27 | ||
| JP10-46855 | 1998-02-27 | ||
| JP22970498A JP4078571B2 (ja) | 1997-10-21 | 1998-08-14 | 記録再生装置、ファイル管理方法、並びに提供媒体 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007298891A Division JP4491752B2 (ja) | 1997-10-21 | 2007-11-19 | 記録再生装置、ファイル管理方法、並びにプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11312378A JPH11312378A (ja) | 1999-11-09 |
| JP4078571B2 true JP4078571B2 (ja) | 2008-04-23 |
Family
ID=27292766
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP22970498A Expired - Lifetime JP4078571B2 (ja) | 1997-10-21 | 1998-08-14 | 記録再生装置、ファイル管理方法、並びに提供媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4078571B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4835714B2 (ja) * | 2009-03-25 | 2011-12-14 | 株式会社日立製作所 | 光ディスク記録装置、光ディスク記録方法、光ディスク再生装置、光ディスク再生方法及び光ディスク |
| JP5131343B2 (ja) * | 2010-12-28 | 2013-01-30 | 株式会社日立製作所 | 光ディスク記録装置、光ディスク記録方法及び光ディスク |
| JP5433711B2 (ja) * | 2012-01-20 | 2014-03-05 | 日立コンシューマエレクトロニクス株式会社 | 記録方法及び再生方法 |
-
1998
- 1998-08-14 JP JP22970498A patent/JP4078571B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11312378A (ja) | 1999-11-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100570907B1 (ko) | 기록및/또는재생장치,파일관리방법및제공매체 | |
| US6501905B1 (en) | File management apparatus and method, and recording medium including same | |
| EP1306846B1 (en) | File operating method using real time recording/reproduction information | |
| US6314235B1 (en) | Recording/reproducing method suitable for recording/reproducing AV data on/from disc, recorder and reproducer for the method, information recording disc and information processing system | |
| CA2462224C (en) | Method and apparatus for recording a digital information signal | |
| US7068918B1 (en) | Recording medium for storing real time recording/reproduction information, method and apparatus for recording and reproducing in real time, and file operating method using the same | |
| US7024534B2 (en) | Information recording medium, information recording method, information recording apparatus, information reproduction method, and information reproduction apparatus | |
| KR100499646B1 (ko) | 파일 관리 방법 및 그것을 사용한 데이터 기록 장치,데이터 재생 장치, 데이터 기록 재생 장치, 및 해당 파일관리 방법으로 기록된 디스크 | |
| KR100374032B1 (ko) | 이동통신시스템의코딩및주파수다이버시티구현방법및장치 | |
| JP4078571B2 (ja) | 記録再生装置、ファイル管理方法、並びに提供媒体 | |
| JP4491752B2 (ja) | 記録再生装置、ファイル管理方法、並びにプログラム | |
| KR100382639B1 (ko) | 실시간기록/재생정보를저장하는기록매체,실시간기록재생방법과장치및이정보를이용한파일조작방법 | |
| JPH0346164A (ja) | 交替セクタ管理方式および情報記録再生システム | |
| US6788876B1 (en) | Information recording medium, information recording/reproduction system apparatus, and information recording/reproduction method | |
| KR100467615B1 (ko) | 실시간 기록/재생 정보를 저장하는 기록 매체, 실시간기록재생방법과 장치 및 이 정보를 이용한 파일 조작 방법 | |
| US20050162988A1 (en) | Method and apparatus for recording and/or reproducing data and write-once information storage medium | |
| RU2289860C2 (ru) | Носитель записи для хранения информации о записи/воспроизведении в реальном масштабе времени | |
| RU2300148C2 (ru) | Носитель записи для хранения информации о записи/воспроизведении в реальном масштабе времени, способ и устройство для записи и воспроизведения в реальном масштабе времени и способ обработки файлов с их использованием | |
| EP1668642A1 (en) | Write-once disc, method of using write-once disc, and data recording and/or reproducing apparatus | |
| JP2002207628A (ja) | ファイル管理方法及びそれを用いたデータ記録装置、データ再生装置、データ記録再生装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050307 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070918 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070920 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071119 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080110 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080123 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110215 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110215 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120215 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130215 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140215 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |