JP4221959B2 - ブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体 - Google Patents
ブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体 Download PDFInfo
- Publication number
- JP4221959B2 JP4221959B2 JP2002185681A JP2002185681A JP4221959B2 JP 4221959 B2 JP4221959 B2 JP 4221959B2 JP 2002185681 A JP2002185681 A JP 2002185681A JP 2002185681 A JP2002185681 A JP 2002185681A JP 4221959 B2 JP4221959 B2 JP 4221959B2
- Authority
- JP
- Japan
- Prior art keywords
- file
- file system
- data
- sub
- blocks
- 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 - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体に係り、特に記録媒体にデータを記録再生する際の管理構造や管理方式を規定するブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体に関する。
【０００２】
【従来の技術】
ファイルシステムは、記録媒体にデータを格納し、取り出すために、記録媒体上の記録領域をどのように使用するかを規定する。これまで様々なＯＳ（オペレーションシステム）や組み込み機器のため多くのファイルシステムが開発されてきたが、その中でＦＡＴファイルシステムは、歴史的に殆どすべてのＯＳでサポートされてきた基本的なファイルシステムの一つで、汎用的でデータ交換性に優れることから、リムーバブルメディアのデファクトスタンダードとなっている。
【０００３】
詳しくは後述するが、その特徴はクラスタと呼ばれる固定ブロック単位のデータ配置方式、ファイル・アロケーション・テーブル（File Allocation Table：ＦＡＴ）でのクラスタチェインを用いた配置管理、階層ディレクトリによるファイル管理などである。その他、クラスタ単位のファイル管理を行うファイルシステムとしてはウィンドウズＮＴのファイルシステムであるＮＴＦＳ（NT File System）などがある。なお，本明細書において、「ウィンドウズ」は登録商標である．
【０００４】
クラスタ単位の管理方法を用いるファイルシステムは、詳しくは後述するが、ファイルサイズとクラスタサイズのミスマッチや、クラスタの分断などによるフラグメンテーションの問題があるため、特開平８−１０１７８３号公報では、２種類のクラスタを用意してファイルサイズによって記録する領域を選ぶ新しいファイルシステムを提案している。
【０００５】
また、光ディスク系の媒体においては、ＩＳＯ９６６０やＩＳＯ９６６０をベースとしたファイルシステム、ＵＤＦ等のファイルシステムが利用されている。ＤＶＤ−Ｖｉｄｅｏにおいては、新しいファイルシステムである ＵＤＦを採用するにあたり、従来のファイルシステムであるＩＳＯ９６６０からも利用できるように、ＵＤＦとＩＳＯ９６６０の２つのファイルシステムが共存するブリッジファイルシステムが採用され、利用者は特定のファイルにアクセスするのにどちらのファイルシステムでも利用できるようになっている。
【０００６】
このように、ブリッジファイルシステムの採用は、情報交換用の記録媒体に新フォーマットを導入する際に利用者に受け入れやすい形式であるといえる。
【０００７】
【発明が解決しようとする課題】
近年のディジタル画像処理技術の進歩により、ＡＶストリームのリアルタイム記録再生を行う機器が発売されるようになった。ＡＶストリームデータを記録媒体に記録再生するために、記録媒体上での配置や取り扱いを規定するためにファイルシステムが使用されるが、従来のファイルシステムは幾つかの課題を抱えており、ＡＶストリームのリアルタイム記録再生にとっては必ずしも最適ではない。
【０００８】
（１）ＦＡＴファイルシステムとその一般的な課題
初めにＦＡＴファイルシステムについて簡単に説明した後、その問題点を述べる。記録媒体は一般にセクタと呼ばれる固定サイズの連続領域を最小単位としてデータの記録再生を行っている。データは記録再生に伴うエラーを回避するため、誤り訂正用の情報やそのほかの管理情報等を付加して記録再生されるが、有効データ部分については一般にそのサイズは２のべき乗で規定される。
【０００９】
例えば、一般に用いられるサイズは、ハードディスクの場合５１２バイト（＝２９バイト）で、ＣＤＲＯＭやＤＶＤＲＯＭ等の光ディスクの場合は一般に２０４８バイト（＝２１１バイト）である（小容量のＭＯは５１２バイト）。ただし、ハードディスクの場合、５１２バイト以外の２のべき乗の論理セクタサイズをとることも可能だが、実質的に５１２バイト以外で用いられることは殆どない。
【００１０】
大容量化した記録媒体においては、この論理セクタ数は膨大になり、効率良く管理するには不利なので、いくつかのファイルシステムでは複数の論理セクタを一定個数まとめて記録媒体を管理する手法をとっている。ウィンドウズＮＴのファイルシステムであるＮＴＦＳ（NT File System）や、ＭＳ−ＤＯＳやウィンドウズ3.1/95で使用されるＦＡＴファイルシステムはこのようなファイルシステムの例である。
【００１１】
図２９はＦＡＴファイルシステムの構造を説明するための図で、全体は図２９（ａ）に示すように、システム領域１、２つのＦＡＴ２、３、ルートディレクトリ領域４、データ領域５から構成される。
【００１２】
データ領域５はクラスタと呼ばれる連続する複数セクタ単位に分割して使用され、クラスタと１対１に対応するエントリを持つ管理テーブルであるＦＡＴを使ってファイルの配置情報を管理する。各クラスタには、順番に番号（クラスタ番号）が振られる。
【００１３】
図２９（ａ）に２及び３で示すように、ＦＡＴは２つあって、１つは予備である。また、システム領域１にはＯＳのブートコードやファイルシステム全体の管理情報などが格納されている。記録データはディレクトリ上でファイルとして記録され、ルートディレクトリを頂点とする任意の木構造からなる階層構造を構成する。
【００１４】
ルートディレクトリ４以下のディレクトリはサブディレクトリと呼ばれ、１つの特殊なファイルとして管理される。ディレクトリの構造はルートディレクトリもサブディレクトリも同じで、ディレクトリエントリのテーブルになっている。
【００１５】
１つのディレクトリエントリには、記録データの内容を表すファイル名等の情報とともに、データの先頭が格納されているクラスタのクラスタ番号をファイルのエントリ情報として記録する。
【００１６】
ＦＡＴはクラスタ番号のテーブルになっており、図２９（ｂ）に示すように、ファイルエントリで示されるクラスタ番号に対応するエントリには、ファイルデータの連結状態を示すために次のクラスタ番号が記録され、複数のクラスタに分散されたデータのつながり（クラスタチェイン）を管理することができる。ファイルの最後のクラスタには最終クラスタであることを示す識別子（ＦＡＴ１６の場合、ＦＦＦＦ）が記録される。このように、ＦＡＴファイルシステムにおいては、ファイルはディレクトリとＦＡＴの２つを用いて管理される。
【００１７】
なお、クラスタ内に欠陥セクタがあると、そのクラスタは使用不可能な領域であることを示す識別子がＦＡＴに記録されるので、このクラスタは使用しない。従って、たとえ１セクタでも不良の領域があった場合は、そのセクタが属するクラスタ全体が使用不可能となるため、クラスタサイズが大きいほど効率的な使用の妨げになる。
【００１８】
ＦＡＴ上のクラスタエントリの内容は、クラスタ番号を意味するので、そのエントリに与えるビット数によって、ファイルシステム全体で扱えるクラスタの数が決まる。ＦＡＴファイルシステムには、そのビット数の違いで幾つかのバージョンがあり、ＦＡＴ１２、ＦＡＴ１６、ＦＡＴ３２ファイルシステムと呼ばれることがある。
【００１９】
ＦＡＴ１２、ＦＡＴ１６、ＦＡＴ３２などの数字の部分はクラスタ番号のビット数を示し、それぞれ１２ビット、１６ビット、３２ビットを意味している。従って、各ファイルシステムが扱えるクラスタの総数は、それぞれおよそ２の１２乗、２の１６乗、２の３２乗個程度になる。実際には予約番号等があるためにこれらの数字より若干小さい値となる。図２９（ｂ）に示すＦＡＴは、ＦＡＴ１６の例である。
【００２０】
ＦＡＴファイルシステムの場合、クラスタサイズは記録媒体の容量によってある一定値に決定され、記録媒体の容量が大きくなるほど大きくなる。図３０は代表的なファイルシステムの容量とクラスタサイズの関係を示す。
【００２１】
しかし、上記のＦＡＴファイルシステムでは、クラスタと呼ぶ一定サイズの記録単位でファイルの記録再生を行うため、記録単位のサイズがファイルサイズにとって必ずしも最適とはならない。
【００２２】
これを解決するための手段として、従来は特開平８−１０１７８３号公報では、通常のクラスタサイズのほかに、クラスタをさらにサブクラスタに分割して、２種類のクラスタサイズを用意しているファイルシステムが開示されている。これによって、大きいファイルは通常のクラスタの領域に、小さいファイルはサブクラスタの領域に、ファイルサイズに応じて選択して記録する。
【００２３】
図３１は上記の特開平８−１０１７８３号公報記載の従来のファイルシステムの一例の構成図を示す。このファイルシステムは、映像情報やオーディオ情報処理用のコンピュータ７に、キャッシュメモリ８を介して直接アクセス装置９としての磁気ディスク装置を接続して構成されており、磁気ディスク装置内の制御部は磁気ディスクに対するヘッダ部の制御と共に、コンピュータ７からの命令に従って、所定のファイルの読み書き制御をする。このとき、制御部は、磁気ディスクを、先頭番地からファイル・アロケーション・テーブルを格納する５１２ｋバイトのシステム領域Ｒ１と、個々のデータファイルを格納するデータ領域Ｒ２に分割して管理する。
【００２４】
データ領域Ｒ２は、５１２ｋバイトの複数のクラスタＣ１、Ｃ２、・・・、Ｃｘに分割され、更にクラスタは１２８ｋバイトの複数のサブクラスタＳＣ１、ＳＣ２、・・・、ＳＣ５に細分割管理してあり、システム領域Ｒ１に設定されたファイル・アロケーション・テーブルにデータ領域Ｒ２に割り付けるべきファイル情報を格納して管理するようにされている。
【００２５】
すなわち、この従来のファイルシステムでは、ファイルサイズの違いによる使用効率やアクセス効率の改善を図るために、記録媒体を、ファイル・アロケーション・テーブルを格納するシステム領域Ｒ１と、個々のデータファイルを格納するデータ領域Ｒ２に分割し、データ領域Ｒ２を大容量の複数のクラスタＣ１、Ｃ２、・・・、Ｃｘに分割するとともに、このクラスタを複数のサブクラスタＳＣ１、ＳＣ２、・・・、ＳＣ５に細分割できるようにしている。さらに、サブクラスタの先頭領域には、システム領域に格納されたファイル・アロケーション・テーブルに関連付ける第２のファイル・アロケーション・テーブルを配置し、サブクラスタ内のファイルの配置を管理している。
【００２６】
従って、ＡＶデータ等の大容量ファイルデータは、システム領域のファイル・アロケーション・テーブルの管理に従って、大容量のクラスタに割り付け、テキストデータ等の小容量のファイルデータはサブクラスタに割り付けることにより、記録媒体の使用効率を向上する。また、上記のサブクラスタＳＣ１、ＳＣ２、・・・、ＳＣ５への分割は、取り扱うべき複数のテキストファイル等の容量に基づいて、システムの初期設定時に予め固定することにより、記録媒体の使用効率を向上する。
【００２７】
なお、特開平８−１０１７８３号公報に記載の用語「ファイル・アロケーション・テーブル」は、ＦＡＴファイルシステムにおけるＦＡＴの名称と同じであるが、内容は異なるので注意を要する。特開平８−１０１７８３号公報における「ファイル・アロケーション・テーブル」は、ファイル名とそのクラスタチェインのリスト構造であり、ＦＡＴファイルシステムのようなクラスタエントリのテーブルは存在しない。
【００２８】
【発明が解決しようとする課題】
しかし、前記ＦＡＴファイルシステムにおけるクラスタによる記録領域の管理方法には一般に次のような弊害がある。
（ａ）外部フラグメンテーション
ＦＡＴファイルシステムのように、クラスタ単位でデータ配置を管理する媒体の運用を続けていると、ファイルの削除、作成といったファイル操作の繰り返しによって、図３２にＸで示すように、媒体上のファイル配置がクラスタ単位でばらばらになっていく。これを外部フラグメンテーションと呼び、外部フラグメンテーションの発生個所では、機械構造を持つ記録デバイスにおいてはヘッドシークが発生するためアクセス速度の低下を招くという欠点がある。
【００２９】
機械構造を持たないフラッシュメモリなどの電気的デバイスにおいては、中央処理装置（ＣＰＵ）の処理能力やバスの転送速度などが十分な場合は、軽微な問題ではあるものの、データ転送手続きを分割する手間等の増加によるパフォーンスの低下という影響がある。
【００３０】
この問題の解消のために、一般にはデフラグというツールを用い、クラスタ単位のデータの並び替えを行ってデータの連続化を行う方法がある。しかしデフラグの実行は膨大な時間とリソースの消費を招くため、アプリケーション実行時の重大な妨げになる。
【００３１】
（ｂ）内部フラグメンテーション
クラスタ単位でデータを扱うため、クラスタサイズ未満のファイルを記録すると、図３２にＹで示すように最終クラスタ内に未使用領域が発生する。これを内部フラグメンテーションまたはクラスタギャップと呼び、記録媒体の使用効率の低下を招く。ここでは、（ａ）の外部フラグメンテーションと対比する意味で内部フラグメンテーションという用語を用いる。一般に、記録容量が大きいほどクラスタサイズが大きくなるため、内部フラグメンテーションが増大し、記録媒体の使用効率が下がるという欠点がある。
【００３２】
（ｃ）欠陥領域
従来のＦＡＴファイルシステムでは、たとえ１セクタでも不良の領域があった場合は、そのセクタが属するクラスタ全体が使用不可能となるため、クラスタサイズが大きいほど効率的な使用の妨げになる。
【００３３】
（ｄ）交替領域
ＤＶＤ−ＲＡＭのように、デバイスが欠陥領域を自動的に交替領域に割り当てるものがあるが、欠陥領域の管理単位がクラスタサイズと一致しないため、クラスタ内の論理アドレスが連続していても物理アドレスは不連続になり、実質的に外部フラグメンテーションが発生していることと同じ状況になってしまう場合がある。
【００３４】
（ｅ）テーブルサイズ
ＦＡＴのテーブルサイズの最大値は、ほぼクラスタに与えるエントリのビット数とクラスタの数の積になるため、記録媒体の容量が大きい場合は膨大なサイズとなる。例えば、２ＧＢのＦＡＴ１６ファイルシステムの場合、ＦＡＴのサイズは約１２０ｋバイトである。新しくファイルを記録する場合は、事前にＦＡＴを調査して未使用領域を探す必要がある。この場合、１２０ｋバイトものテーブルをサーチして空き領域を探す必要があるため効率が悪い。
【００３５】
また、大きいサイズのテーブルをメモリ上に保持することは、システムリソースを圧迫し、特に組み込み用機器等、リソースが貧弱な機器にとっては甚だしく不利である。かといってメモリ上にテーブルを持たないと、上記データが必要になる度に、記録媒体にアクセスする必要があるため効率が低下するという問題がある。
【００３６】
また、前記の特開平８−１０１７８３号公報には、ファイルサイズの違いによる使用効率やアクセス効率の改善を図るという、特定の用途に最適化するための新しいファイルシステムが開示されている。しかし、このように特定の用途に最適化するために新しいファイルシステムを導入すると、通常のコンピュータシステムでは、この媒体にアクセスできないという問題がある。
【００３７】
この場合、新しいファイルシステム用のデバイスドライバ等をシステムに組み込む必要があるため、ユーザーにシステムの変更や手間を要求することになり、情報交換性という点ではあまり好ましくない。また、各種コンピュータシステムに対応するために多くの種類のドライバを配布し、それを適切に誤りなく組み込むことは難しい。
【００３８】
（２）その他のファイルシステムについて（ＮＴＦＳ）
ＮＴＦＳは、ＦＡＴファイルシステムと同様にクラスタ単位のファイル配置を行うが、ＦＡＴよりも比較的フラグメンテーションが発生しにくく、信頼性を向上させる仕組みや、より細かい属性設定が可能などのいくつかの特徴を持つ。従って、ＦＡＴファイルシステムより、柔軟で高度な管理が可能である。
【００３９】
ＮＴＦＳの構造上の特徴は、パーティション内のすべてのファイルやディレクトリ毎に固定長の管理レコードを作成し、これを集中的に管理している。この管理レコード群はマスター・ファイル・テーブル（ＭＦＴ：Master File Table）と呼ばれる１つのファイルである。
【００４０】
各管理レコードは固定長であり、このサイズに納まるような小さいファイルは管理レコード内で完結するように保存される。一方、管理レコードのサイズを越える大きいファイルは、ＭＦＴ以外の領域に一連の新しいクラスタが割り当てられ、そこへのインデックスが管理レコードに保存される。従って、このような大きいファイルではＦＡＴファイルシステムと同様にクラスタ単位のフラグメンテーションが発生する可能性がある。従って、この点については特にＦＡＴファイルシステムより優れているわけではない。
【００４１】
また、ＭＦＴ自体も一つのファイルであるため、ＭＦＴに最初に割り当てられるサイズを越えると、その度に３２レコード分の拡張が行われ、フラグメンテーションが発生する。ＮＴＦＳでは、ＭＦＴのフラグメンテーションは顕著な効率低下を招くので望ましくない。
【００４２】
（３）その他のファイルシステムについて（ＩＳＯ９６６０とＵＤＦ）
光ディスクではＣＤ−ＲＯＭの標準論理フォーマットとして用いられているＩＳＯ９６６０規格に対し、再生専用・追記・書き換え型の物理特性を持つ各ディスクに共通に適用可能で、汎用性や拡張性を重視したＵＤＦ（Universal Disk Format）ファイルシステムが開発されており、ＤＶＤやＣＤ−ＲＷ等で採用されている。
【００４３】
ＩＳＯ９６６０とＵＤＦのどちらも論理セクタの連続する塊としてファイル配置を表現するファイルシステムであるが、管理構造は異なっている。ＵＤＦのボリューム空間は、ＣＤ−ＲＯＭのボリューム構造を含むように構成できるようになっており、ＤＶＤ−ＲＯＭディスクなどの再生専用ディスクでこのようなブリッジ構造を実現している。
【００４４】
このようなブリッジ構造の採用により、既存のコンピュータシステムは新しいファイルシステムであるＵＤＦファイルシステムを使用しなくても、標準的に搭載されているＩＳＯ９６６０ファイルシステムを使用して、ディスク上に記録されたファイルにアクセスすることが可能になる。
【００４５】
（４）特定用途に対する問題点
近年、ハードディスクドライブ（ＨＤＤ）を用いて、ＡＶストリームのリアルタイム記録再生を行う機器が発売されるようになった。このＡＶストリームは、高いビットレートでリアルタイムに伝送する必要があるため、外部フラグメンテーションによるアクセス効率の低下は、リアルタイムの記録再生に障害となる場合がある。
【００４６】
そこで、クラスタ内の領域は連続領域に記録されることから、外部フラグメンテーションの影響を少なくするために、クラスタサイズを大きくする方法が考えられる。これによって、データに連続的にアクセスできるようになるため、アクセス速度の保証が可能になり、ＡＶストリーム等のリアルタイム記録再生に有利である。たとえ、外部フラグメンテーションが発生しても、もともとクラスタサイズが大きいため、ヘッドシークによるアクセス速度の低下を無視できる程度に下げることができる。
【００４７】
このようにクラスタサイズを大きくすると、外部フラグメンテーションの影響を最小化することが可能だが、その反面、サイズの小さなファイルに対して内部フラグメンテーションが増大し、ハードディスクの使用効率が低下するという問題がある。
【００４８】
すなわち、ＡＶストリームは一般にファイルサイズが大きくなるため、外部フラグメンテーションに関する問題は少ないが、これを管理するためのファイルや一般のファイルは、ＡＶストリームと比較するとサイズが小さく、しかも数多く作成されるため、これらのファイルに対する内部フラグメンテーションがハードディスクの効率的な使用を妨げていた。
【００４９】
（５）リムーバブルメディアの可換性の問題
前記（４）のような問題を解決するために新しいファイルシステムを導入する場合、組み込み型の記録媒体であれば、閉じたシステムであるため全く独自のファイルシステムを導入しても問題ない。
【００５０】
しかし、リムーバブルのＨＤＤや不揮発性メモリカード等を搭載したムービーで利用する場合、これらの記録媒体をパソコンなどの既存のコンピュータシステムで利用できれば優れた情報交換性を発揮できる。この時、記録媒体に対して独自のファイルシステムでファイルを記録していた場合、既存のコンピュータシステムは、そのままでは認識できない。このような場合はユーザーに対しそのファイルシステムのためのデバイスドライバを組み込むことが要求され、情報交換性を著しく阻害することになる。
【００５１】
本発明は、以上の点に鑑みなされたもので、２つのファイルシステムを共存させ、どちらのファイルシステムからでも、記録された情報をアクセスし得るブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体を提供することを目的とする。
【００５２】
また、本発明の他の目的は、サイズの大きなＡＶストリームデータから、サイズの小さなＡＶストリームの管理情報などのファイルまでを最適に記録し得るブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体を提供することにある。
【００５３】
また、本発明の他の目的は、殆どすべてのコンピュータシステムに適用し得るブリッジファイルシステム及び記録媒体を提供することを目的とする。
【００５４】
更に、本発明の他の目的は、ＦＡＴシステムを使用する場合よりも高度な管理が可能なブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体を提供することにある。
【００５５】
また、本発明の更に他の目的は、論理セクタ単位に管理し得るブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体を提供することにある。
【００５６】
【課題を解決するための手段】
上記の目的を達成するために。第１の発明は、記録媒体上の連続する記録領域を複数の論理セクタから構成される一定サイズの基本ブロック毎に分割し、該基本ブロック単位でデータを配置して管理する第１の管理方法と、任意の前記基本ブロックを各々同一サイズの複数の論理セクタから構成される複数のサブブロックに分割し、そのサブブロック単位でデータを配置して管理する第２の管理方法を持ち、前記第１及び第２の管理方法のうち選択した管理方法でデータを記録再生する第１のファイルシステムと、前記記録領域を前記サブブロックと同一サイズのブロック単位でデータを配置して管理する第２のファイルシステムとが共存するブリッジファイルシステムであって、前記記録領域のデータファイルに対し、前記第１及び第２のファイルシステムの両方からアクセス可能な管理構造を有し、前記第１のファイルシステムは、前記記録領域内の前記基本ブロック毎の状態を表すフラグの集合とその管理情報が記録された第１のビットマップテーブルを前記記録領域上に配置し、前記サブブロックに分割された前記基本ブロックは、その基本ブロック内のサブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブルを該当する基本ブロック毎に対応付けて前記記録領域上に配置し、前記第２のファイルシステムの管理情報のうち、前記第１のファイルシステムが参照可能な前記記録領域に配置される管理情報がある場合は、前記第１のファイルシステムの前記サブブロックのエリアに配置し、前記第２のファイルシステムは、前記第１及び第２のビットマップテーブルをファイルとして参照可能で、前記第２のファイルシステムにおけるブロック毎の使用状態とファイルの配置状態を管理する第３のテーブルを持つブリッジファイルシステムである。
【００５７】
また、第２の発明は、第１のブリッジファイルシステムにおいて、前記第２のファイルシステムはＦＡＴファイルシステムであり、前記第３のテーブルはファイルアロケーションテーブル（ＦＡＴ）である。
【００５８】
また、第３の発明は、第１のブリッジファイルシステムにおいて、前記第２のファイルシステムはＮＴＦＳファイルシステムであり、前記第３のテーブルはマスターファイルテーブル（ＭＦＴ）である。
【００５９】
また、第４の発明は、第１のブリッジファイルシステムにおいて、前記第１のファイルシステムは、前記記録領域内の前記基本ブロック毎の状態を表すフラグの集合とその管理情報が記録された第１のビットマップテーブルを前記記録領域上に配置し、前記サブブロックに分割された前記基本ブロックは、その基本ブロック内の前記サブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブルを該当する基本ブロック毎に対応付けて前記記録領域上に配置し、前記第２のファイルシステムは、前記第１及び第２のビットマップテーブルをファイルとして参照可能で、前記第２のファイルシステムの管理情報のうち、前記第１のファイルシステムのデータエリアに配置される管理情報がある場合は、前記第１のファイルシステムの前記サブブロックのエリアに配置し、前記記録領域のデータファイルに対し、前記第１及び第２のファイルシステムの両方からアクセス可能な管理構造を有する。
【００６０】
また、第４の発明は、第４のブリッジファイルシステムにおいて、前記第２のファイルシステムは、ＩＳＯ９６６０またはＵＤＦである。
【００６１】
また、第６の発明は、記録媒体上の連続する記録領域を複数の論理セクタから構成される一定サイズの基本ブロック毎に分割し、該基本ブロック単位でデータを配置して管理する第１の管理方法と、任意の前記基本ブロックを各々同一サイズの複数の論理セクタから構成される複数のサブブロックに分割し、そのサブブロック単位でデータを配置して管理する第２の管理方法を持ち、前記第１及び第２の管理方法のうち選択した管理方法でデータを記録再生する第１のファイルシステムと、前記記録領域を前記サブブロックと同一サイズのブロック単位でデータを配置して管理する第２のファイルシステムとが共存するブリッジファイルシステムをコンピュータに搭載したコンピュータシステムであって、前記記録領域のデータファイルに対し、前記第１及び第２のファイルシステムの両方からアクセス可能な管理構造を有し、前記第１のファイルシステムは、前記記録領域内の前記基本ブロック毎の状態を表すフラグの集合とその管理情報が記録された第１のビットマップテーブルを前記記録領域上に配置し、前記サブブロックに分割された前記基本ブロックは、その基本ブロック内のサブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブルを該当する基本ブロック毎に対応付けて前記記録領域上に配置し、前記第２のファイルシステムの管理情報のうち、前記第１のファイルシステムが参照可能な前記記録領域に配置される管理情報がある場合は、前記第１のファイルシステムの前記サブブロックのエリアに配置し、前記第２のファイルシステムは、前記第１及び第２のビットマップテーブルをファイルとして参照可能で、前記第２のファイルシステムにおけるブロック毎の使用状態とファイルの配置状態を管理する第３のテーブルを持つブリッジファイルシステムをコンピュータに搭載したコンピュータシステムである。
【００６２】
また、第７の発明は、記録媒体上の連続する記録領域を複数の論理セクタから構成される一定サイズの基本ブロック毎に分割し、該基本ブロック単位でデータを配置して管理する第１の管理方法と、意の前記基本ブロックを各々同一サイズの複数の論理セクタから構成される複数のサブブロックに分割し、そのサブブロック単位でデータを配置して管理する第２の管理方法を持ち、前記第１及び第２の管理方法のうち選択した管理方法でデータを記録再生する第１のファイルシステムと、前記記録領域を前記サブブロックと同一サイズのブロック単位でデータを配置して管理する第２のファイルシステムとが共存するブリッジファイルシステムを用いたデータ管理方法であって、前記第１及び第２のファイルシステムは、前記第１のファイルシステムに基づき前記記録領域に記録された第１のデータファイルと前記第２のファイルシステムに基づき前記記録領域に記録された第２のデータファイルのいずれに対しても、それぞれアクセス可能であり、前記第１のデータファイルを、前記基本ブロック毎の状態を表すフラグの集合とその管理情報とからなる第１のビットマップテーブル、又は前記サブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブルが、前記基本ブロック単位又は前記サブブロック単位で記録されたテーブル領域と、データが前記基本ブロック単位又は前記サブブロック単位で記録されたデータ領域とが分離された構造とし、
前記第１及び第２のビットマップテーブルの前記フラグの集合には、そのビットマップテーブルにより管理する前記第１のデータファイル中のデータ領域に、専用のアクセス手段によってのみアクセス可能な一時削除ファイルが記録されていることを示す第１のフラグと、予め記録する領域を確保するために特別に設けられた予約領域ファイルが確保されていることを示す第２のフラグとを含み、前記第１及び第２のビットマップテーブルにより、前記データ領域に記録するデータを管理することを特徴するブリッジファイルシステムを用いたデータ管理方法である。
【００６５】
【発明の実施の形態】
次に、本発明の一実施の形態について図面と共に説明する。図１は本発明になるブリッジファイルシステム及び記録媒体の一実施の形態の概略説明図を示す。同図において、記録媒体１００上の連続する記録領域には、第１のファイルシステムの第１又は第２のビットマップテーブル１０１と、第２のファイルシステムの第３のテーブル１０２とが記録されている。また、第１のファイルシステムによるファイル１０３、１０４が記録媒体１００上に記録されている。
【００６６】
ここで、上記の第１のファイルシステムは、記録媒体１００上の連続する記録領域を複数の論理セクタから構成される一定サイズの基本ブロック毎に分割し、基本ブロック単位でデータを配置して管理する第１の管理方法と、任意の前記基本ブロックを各々同一サイズの複数の論理セクタから構成される複数のサブブロックに分割し、そのサブブロック単位でデータを配置して管理する第２の管理方法を持ち、前記第１及び第２の管理方法のうち選択した管理方法でデータを記録再生する。
【００６７】
この第１のファイルシステムは、上記の記録領域内の基本ブロック毎の状態を表すフラグの集合とその管理情報が記録された第１のビットマップテーブル１０１を記録媒体１００上に配置し、サブブロックに分割された基本ブロックは、その基本ブロック内のサブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブル１０１を該当する基本ブロック毎に対応付けて記録媒体１００上に配置し、第２のファイルシステムの管理情報のうち、第１のファイルシステムのデータエリアに配置される管理情報がある場合は、第１のファイルシステムの前記サブブロックのエリアに配置する。
【００６８】
また、上記の第２のファイルシステムは、上記の記録領域をサブブロックと同一サイズのブロック単位でデータを配置して管理する既存のファイルシステムである。この第２のファイルシステムは、第１及び第２のビットマップテーブルをファイルとして参照可能で、第２のファイルシステムにおけるブロック毎の使用状態とファイルの配置状態を管理する第３のテーブル１０２が記録されている。
【００６９】
これにより、第１のファイルシステムに対応したコンピュータシステム１０５は、第１又は第２のビットマップテーブル１０１に基づいて、ファイル１０３や１０４の再生ができる。また、既存の第２のファイルシステムが搭載されているコンピュータシステム１０６においても、第３のテーブル１０２に基づいて記録されたファイル１０３及び１０４にアクセスできる。このように、本発明では第１及び第２のファイルシステムのどちらからもアクセスできるようにしたので、第２のファイルシステムとして、コンピュータシステムに標準的に搭載されているファイルシステムを採用すれば情報交換が容易になる。
【００７０】
なお、第１のファイルシステムに対応したコンピュータシステム１０５が、第３のテーブル１０２に基づいて、ファイル１０３、１０４をアクセスすることは可能であるが、第１又は第２のビットマップテーブル１０１を参照した方が最大効率でファイル１０３、１０４をアクセスできるので、第３のテーブル１０２を用いてアクセスすることは特に必要ではない。
【００７１】
次に、本発明のブリッジファイルシステムの一実施の形態のデータ領域の使用方法について説明する。ｎを２以上の自然数、ｍを任意の自然数とすると、複数の一定サイズの論理セクタで構成される記録媒体のデータ領域をｍｎセクタ毎の基本ブロックに分割し、識別番号として先頭から順番にブロック番号を振る（ｍｎはｍ×ｎの意味）。
【００７２】
各基本ブロックは、連続するｍセクタからなる、ｎ個のサブブロックに分割することができる。データを記録する場合は、基本ブロック単位またはサブブロック単位に記録する。
【００７３】
図２は本発明の記録媒体の記録領域の先頭付近の利用状況の一実施の形態を示す。同図において、各ブロックのサイズはｍｎセクタ分のサイズであり、ブロック番号１，２，４が基本ブロック単位で使用され、ブロック番号０、３がｎ個のサブブロックに分割して使用されている。サブブロックへの分割は必要に応じて行うものとし、フォーマット時は分割されていない基本ブロックのみでもよい。
【００７４】
記録媒体へのデータ配置をこのようにしておくことにより、一般に基本ブロックよりも大きいサイズのファイルは分割しないブロックにそのまま記録し、基本ブロックよりある程度小さいサイズのファイルは、サブブロックに記録することによって、２つのメリットが得られる。
【００７５】
１つは、大きいファイルは基本ブロック単位でしか外部フラグメンテーションが発生しないので、ＨＤＤ等に適用した場合、ヘッドシークの発生を最小限にでき、アクセス効率が向上する点である。もう１つは、小さいファイルはサブブロックに配置するため、内部フラグメンテーションによって発生する可能性のある無駄な領域をサブブロックのサイズ以下に抑えることができる点である。
【００７６】
サブブロックへ分割する際のサイズの基準は、任意に設定できるが、基本ブロックに占めるデータの割合が大きい場合に、基本ブロックとして使用するのが一般的にはよい。例えば、基本ブロックサイズの８０％を越える場合には基本ブロックとして扱い、そうでない場合はサブブロックに分割する。この設定によって、基本ブロックで発生する内部フラグメンテーションによる使用効率の低下は、最終基本ブロックサイズの２０％以下に抑えることができる。
【００７７】
また、基本ブロックより大きいファイルは、複数の基本ブロックに書き込まれることになるが、最終ブロックについては基本ブロックより小さいファイルと同等の状況になるので、このようなファイルに対しては、最終ブロック以外は基本ブロック単位で扱い、最終ブロックについては、前記基準を適用して、場合によってはサブブロックに分割するようにしてもよい。
【００７８】
なお、この基準は絶対的なものではなく、０％から１００％まで、システムやアプリケーションのポリシーによって自由に設定することができる。例えば、将来追加書き込みが予想されるファイルは、無条件に基本ブロックとして扱ったほうがよい。その理由は、サブブロックに分割した後で残りの領域に別なファイルが書き込まれた場合、追加書きこみデータを連続領域に書き込めないからである。逆に、アクセス性よりも使用効率の方が重要であるなら、サブブロックへの分割の優先度をあげ、必ず分割するようにしてもよい。
【００７９】
次に、本発明において、前記２種類のデータ配置を効率良く管理する方法について説明する。
【００８０】
本発明の特徴の１つは、データ領域の使用状況等を示す管理情報をデータの配置情報と分離して用意したことである。この管理情報は、データ領域の２種類の利用方法に対応した２種類のビットマップテーブルによって実現している。
各基本ブロックおよびサブブロックは、それぞれ自分のブロックに対応する数ビットのフラグを持ち、このフラグの組み合わせによって、ブロックの使用状態等を判断することができる。
【００８１】
図３は本発明のブリッジファイルシステムにおけるブロック毎の管理情報を示すための各種フラグの定義例を示す。図３では、一つのブロックについて、ビット（ｂｉｔ）０〜３の４つのフラグを割り当てており、第１と第２のビットマップテーブルでほぼ共通に使用することができる。
【００８２】
同図において、ビット０のスケール（ｓｃａｌｅ）フラグは、基本ブロックを基本ブロック全体として使用しているか、サブブロックに分割して使用しているかを示すフラグで、０のときサブブロックに分割して使用していることを示す。このフラグは、第１のビットマップテーブルで使用するときのみ有効で、第２のビットマップテーブルでは、使用しない。あるいは、ここでは解説しない別な用途に用いてもよい。
【００８３】
ビット１のユーザブル（ｕｓａｂｌｅ）フラグは、そのブロックに利用可能な空き領域があるかどうかを示すフラグで、ｓｃａｌｅフラグの内容によって若干意味が異なり、ｓｃａｌｅフラグが１の時は、その基本ブロックが完全に未使用であるかどうかを示し、ｓｃａｌｅフラグが０の時は、完全に未使用なサブブロックが存在するかどうかを示す。すなわち、どちらの場合も利用可能なブロックがある場合に１にする。
【００８４】
従って、ｓｃａｌｅフラグとｕｓａｂｌｅフラグの２つのビットを検索することによって、基本ブロック又はサブブロック単位で未使用なブロックがあるかどうか簡単に判断することができる。
【００８５】
ビット２のプリアロケーテッド（ｐｒｅａｌｌｏｃａｔｅｄ）フラグは、そのブロックを記録に先だって予約しておくためのフラグであり、１のときにそのブロックが予約領域であることを示す。更に、ビット３のディフェクト（ｄｅｆｅｃｔ）フラグは、１のときはそのブロックに欠陥領域があって使用できないことを示し、０のときはそのブロックに欠陥領域がなく使用可能であることを示す。
【００８６】
なお、図３は一例であって、予約領域をサポートしない場合は、プリアロケーテッドフラグはなくてもよい。また、欠陥領域をサポートしない場合は、ｄｅｆｅｃｔフラグはなくてもよい。また、図３に示す以外のその他の管理情報を示すフラグがあってもよい。
【００８７】
また、第１のビットマップテーブルにおいては、ｓｃａｌｅフラグとｕｓａｂｌｅフラグの両方のビットが必要だが、第２のビットマップテーブルにおいては、ｕｓａｂｌｅフラグのビットのみ必要なので、ブロックに割り当てるビット数を前者は２ビット、後者は１ビットにしてもよい。構造を同じにすれば、処理を共通化できるメリットがあるので、同じビット数を割り当てて、第２のビットマップテーブルではｓｃａｌｅのフラグに相当するビットを使用せず、あるいは別な用途に用いるようにしてもよい。
【００８８】
本実施の形態では、１つのブロックが持つ情報は図３に示すように高々数ビットであるため、ビットマップテーブル全体のサイズは極めて小さく、大容量の記録媒体であっても、媒体全体の使用状況等を高速に取得できる。また、サイズが小さいため、機器のメモリ上に読みこんでもシステムリソースを圧迫しないというメリットがある。
【００８９】
例えば、ＦＡＴファイルシステムでは、データ領域の使用状況等とデータの配置情報が分離されず一体となっており、クラスタチェインを記録した１つの巨大なテーブルとなってしまう。このため、記録時には媒体の空き領域を探すのに時間と手間がかかる欠点があり、再生時もクラスタのリンク情報を辿らなければならず、やはり時間と手間がかかり、いずれも効率的でない。また、ＦＡＴのテーブルは、サイズが大きいためメモリ上でシステムのリソースを圧迫する。２ＧバイトのＦＡＴ１６ファイルシステムでは、ＦＡＴサイズは約１２０ｋバイトにもなる。
【００９０】
これに対し、本実施の形態では、記録時はサイズの小さいビットマップテーブルをサーチして空き領域を探すだけなので、極めて高速に効率良く情報を取得でき、リソースも殆ど消費しない。また、再生時にはビットマップテーブルの参照は不要で、直接ファイルの管理情報から、配置状況を取得できる。
【００９１】
前記２Ｇバイトの例で比較すると、基本ブロックサイズを１.５Ｍバイト、サブブロックサイズをＦＡＴ１６ファイルシステムと同じ３２Ｋバイトとした場合、１つのブロックの状態を表すのに４ビット使用すると仮定すると、第１のビットマップテーブルの本体部分は僅か６８０バイト程度となり、ＦＡＴファイルシステムの１８０分の１である。第２のビットマップテーブルは、１つにつきテーブル部分が２４バイトと、これも非常に小さい。
【００９２】
本実施の形態においては、全体の使用状況を示すサイズの小さい第１のビットマップテーブルがあるため、全体の状況を素早く取得することが出来、必要に応じて参照される第２のビットマップテーブルは、まとめて配置することができるため、サブブロックの状況も素早く取得することができる。
【００９３】
次に、本発明のブリッジファイルシステムの一実施の形態における第１及び第２のビットマップテーブルの一例について説明する。図４は第１のビットマップテーブルの一例を示し、図５は第２のビットマップテーブルの一例を示す。
【００９４】
図４の第１のビットマップテーブルおいて、スペース・アロケーション・インフォメーション・デスクリプタ（Ｓｐａｃｅ＿Ａｌｌｏｃａｔｉｏｎ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｄｅｓｃｒｉｐｔｏｒ）は、第１のビットマップテーブルの先頭に位置し、第１のビットマップテーブルであることを示す識別子の他、第１のビットマップテーブル全体のサイズなどの情報が格納されている。
【００９５】
サイズオブＬＣ（Ｓｉｚｅ＿ｏｆ＿ＬＣ）は、基本ブロックのサイズ、サイズオブマップ（Ｓｉｚｅ＿ｏｆ＿ＭＡＰ）は、ビットマップ本体部分のサイズ、サイズオブＤＳＣ（Ｓｉｚｅ＿ｏｆ＿ＤＳＣ）は、デフォルトのサブブロックサイズ、サイズオブＤＳＣＭＡＰ（Ｓｉｚｅ＿ｏｆ＿ＤＳＣＭＡＰ）は、デフォルトの第２のビットマップテーブルのサイズ、ナンバー・オブ・ブロック（Ｎｕｍｂｅｒ＿ｏｆ＿Ｂｌｏｃｋ：ＮＢ）は、基本ブロックの数、ナンバー・オブ・スモールブロック（Ｎｕｍｂｅｒ＿ｏｆ＿Ｓｍａｌｌ＿Ｂｌｏｃｋ）は、基本ブロックのうち、サブブロックに分割されている基本ブロックの数、ＳＡＩアラインメント（ＳＡＩ＿Ａｌｉｇｎｍｅｎｔ）は、第１のビットマップテーブルをスタッフィングデータによって、５１２バイトの倍数のサイズにした場合のサイズ、ＳＢＩ＿Ｄアラインメント（ＳＢＩ＿ＤＡｌｉｇｎｍｅｎｔ）は、第２のビットマップテーブルをスタッフィングデータによって、５１２バイトの倍数のサイズにした場合のデフォルトサイズ、ベーシック・ブロック・ビットマップ（Ｂａｓｉｃ＿Ｂｌｏｃｋ＿Ｂｉｔｍａｐ）は、サイズがＮＢ／２バイトのビットマップ本体をそれぞれ示す。ベーシック・ブロック・ビットマップの要素の１つが、図３に示すフラグを表す。
【００９６】
図５の第２のビットマップテーブルにおいて、スモール・ブロック・インフォメーション・デスクリプタ（Ｓｍａｌｌ＿Ｂｌｏｃｋ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｄｅｓｃｒｉｐｔｏｒ）は、第２のビットマップテーブルの先頭に位置し、第２のビットマップテーブルであることを示す識別子の他、第２のビットマップテーブル全体のサイズなどの情報が格納されている。
【００９７】
また、ベーシック・ブロック・ナンバー（Ｂａｓｉｃ＿Ｂｌｏｃｋ＿Ｎｕｍｂｅｒ）は、所属する基本ブロックの識別番号、ブロックアドレス（Ｂｌｏｃｋ＿Ａｄｄｒｅｓｓ）は先頭ブロックの論理ブロックアドレス（パーティション先頭を０番地とする論理セクタ単位のアドレス番号）、ＳＢＩアラインメント（ＳＢＩ＿Ａｌｉｇｎｍｅｎｔ）は、スタッフィングデータによって、５１２バイトの倍数のサイズにした場合のサイズで、第１のビットマップテーブルにおける、ＳＢＩ＿ＤＡｌｉｇｎｍｅｎｔと異なる場合、このＳＢＩ＿Ａｌｉｇｎｍｅｎｔの方を優先する。
【００９８】
サイズオブＬＣ（Ｓｉｚｅ＿ｏｆ＿ＬＣ）は、対応する基本ブロックのサイズ、サイズオブＳＣ（Ｓｉｚｅ＿ｏｆ＿ＳＣ）はサブブロックサイズで、第１のビットマップテーブルにおけるサイズオブＤＳＣと異なる場合は、このサイズオブＳＣの方を優先する。サイズオブＳＣＭＡＰ（Ｓｉｚｅ＿ｏｆ＿ＳＣＭＡＰ）は、第２のビットマップテーブルのサイズで、第１のビットマップテーブルにおけるサイズオブＤＳＣＭＡＰと異なる場合は、このサイズオブＳＣＭＡＰの方を優先する。
【００９９】
また、ナンバーオブＳＣ（Ｎｕｍｂｅｒ＿ｏｆ＿ＳＣ：ＮＳＣ）は、この基本ブロック内に含まれるサブブロックの数、スモール・クラスタ・ビットマップ（Ｓｍａｌｌ＿Ｃｌｕｓｔｅｒ＿Ｂｉｔｍａｐ）は、サイズがＮＳＣ／２バイトのビットマップ本体を示す。スモール・クラスタ・ビットマップの要素の１つ１つが、図３に示すフラグを表す。ただし、図３のＳｃａｌｅフラグは無効なフラグである。
【０１００】
第１のビットマップテーブルは、媒体全体又は媒体がパーティションに分割されている場合はパーティション全体に対して１つ存在する。なお、安全性を高めるために、内容が同一なコピーを別に用意してもよい。第２のビットマップテーブルは、サブブロックに分割された基本ブロック毎に存在するので、０個から基本ブロックの個数までいろいろな場合がある。コピーを用意する場合は、コピーに応じた数だけ増加する。
【０１０１】
第１のビットマップテーブルには、第２のビットマップテーブルに関するデフォルトのサイズのパラメータがいくつか用意されており、サブブロックに分割する際のガイドラインとして使用することができる。第２のビットマップテーブルのパラメータを常にこのデフォルト値に従って作成することにより、第２のビットマップテーブルの管理がより容易になる。
【０１０２】
一方、すべてのパラメータをデフォルト値に合わせなくても、第２のビットマップテーブルのパラメータを優先するようにしたので、基本ブロック単位でサブブロックの利用方法を独自に設定することができ、記録するファイルの性質に応じたダイナミックな運用が可能である。例えば、ある基本ブロックと別な基本ブロックで、サブブロックのサイズを異なる値に設定することができる。どのような使い方をするかは、アプリケーションが自由に設定してよい。
【０１０３】
本発明によるブリッジファイルシステムは記録するデータを限定するものではないが、特定の用途のアプリケーションに関連するデータを記録するのに特に適している。このような例の１つとして、映像や音声をリアルタイムで記録し、プレイリストを使って通常再生し、サーチ情報を使って特殊再生するようなアプリケーションがある。
【０１０４】
ＡＶのストリームデータは、一般にサイズが大きく、リアルタイム性が要求されるため、本発明における基本クラスタ単位での記録再生に最適である。また、プレイリストやサーチのための情報など、ＡＶのストリーム以外のデータはＡＶデータと比較してサイズがはるかに小さいために、サブブロックに記録するのに最適である。また、基本ブロック単位に記録するファイルであっても、最終ブロックを有効に使用するため、最終ブロックのみサブブロックに分割してもよい。
【０１０５】
このようなアプリケーションでは、サイズの大きいデータと小さいデータが別に存在することが予めわかっているため、フォーマット時に記録媒体をいくつかの領域に分け、例えば基本ブロック単位で使用する領域とサブブロック単位で分割して使用する領域の２つに分けてもよい。このように、予め領域を定めて使用すると、基本ブロック中にサブブロックに分割されたエリアが存在しないため、混在した場合よりも基本ブロック単位の外部フラグメンテーションが発生しにくい。ただし、ファイルの最終部分が格納される。基本ブロックについては、元々データ境界であるため、基本ブロックとして利用する領域であっても、例外的にサブブロックに分割し、空き領域を効率的に使用してもよい。
【０１０６】
このように、予め領域を定める場合は、使用中に領域の過不足が生じる可能性があるので、任意の領域を拡大、縮小、移動、挿入、削除、コピーなどの操作によってダイナミックに変更できるようにするとよい。
【０１０７】
ＡＶストリームデータは、データの信頼性よりもリアルタイム性が要求され、一方プレイリストやサーチのための情報などは、データの信頼性の方が重要なので、前記分割した領域に対して、予めエラー発生時のリカバリー方法を個別に設定するとよい。
【０１０８】
例えば、ＡＶストリームデータを記録再生する基本ブロック単位の領域は、エラー発生時のリトライを行わないものとし、プレイリストやサーチのためのデータを記録再生するサブブロック領域は、ある程度のリトライを許すことによって、データの性質に応じた最適な記録再生が行える。
【０１０９】
このようなエラー発生時の対応方法を設定した情報は、管理情報としてフォーマット時に記録媒体に保存しておくか、後から必要に応じて設定変更する。また、記録媒体がハードウェア的にそのような仕組みに対応している場合は、その仕組みに合わせた手続によって対応方法の設定もしくは参照を行うことにより、エラー発生に対応すればよい。
【０１１０】
次に、本発明におけるサブブロックの活用方法について説明する。サブブロックの活用方法には、サイズの小さいファイルへの適用のほか、欠陥領域への適用がある。記録媒体は、一般に初期不良あるいは使用中の不良発生によって欠陥領域が発生することがある。ＦＡＴファイルシステムにおいては、このような欠陥領域はクラスタ単位で欠陥であることを示し、使用しないようにする。従って、たとえ１セクタの不良であっても、クラスタ全体が使用不能になってしまう。このため、クラスタサイズが大きくなればなるほど、欠陥セクタのために無駄になる領域が増えてしまい、記録媒体の使用効率が下がってしまう。
【０１１１】
これに対して、本発明においては欠陥領域が存在する場合、これを含む基本ブロックをサブブロックに分割することで、無駄になる領域をサブブロック内にとどめることができる。さらに、サブブロックのサイズは基本ブロック毎に独自に設定することができるため、該当基本ブロックにおけるサブブロックのサイズを論理セクタサイズと等しくすることにより、無駄な領域を完全になくすことも可能である。
【０１１２】
また、基本ブロック全体が欠陥領域である場合は、その基本ブロックはサブブロックには分割せず、第１のビットマップテーブルの該当する基本ブロックに対応するｄｅｆｅｃｔフラグをセットする。
【０１１３】
また、サブブロックに分割すると正常なサブブロックがある場合は、その基本ブロックはサブブロックに分割して使用し、第２のビットマップテーブル内でサブブロック毎に欠陥領域があるかどうかをｄｅｆｅｃｔフラグに反映する。
【０１１４】
記録媒体によっては、ＤＶＤ−ＲＡＭのようにデバイスが欠陥管理機能を持っていて、欠陥領域を正常領域に自動的にマッピングし直すものがある。このように正常領域にマッピングされた領域のことを交替領域と呼ぶ。交替領域の存在は一般にアプリケーションからは見えないため、連続領域にアクセスしているつもりでも物理的には不連続にアクセスしていることがある。
【０１１５】
本発明では、基本ブロックを物理的に連続する領域で構成することによってＨＤＤなどにおけるヘッドシークを避け、ＡＶストリームなどのリアルタイムアクセスが必要な用途に最適に使用できることを可能にしている。従って、ＡＶストリームに使用する場合は、基本ブロック内に交替セクタが存在しない方がよい。サブブロックについては、そのような制約はないので交替領域があってもよい。
【０１１６】
従って、ＡＶストリームの記録再生を目的とする場合は、記録媒体上に交替セクタがある時は、前記交替セクタを含む基本ブロックをサブブロックに分割して使用することで、基本ブロック単位で使用する場合には交替セクタが存在しないことを保証することができる。なお、基本ブロック全体が交替セクタになっていて、交替領域が連続しているならそのまま基本ブロックとして使用してもよい。
【０１１７】
次に、予約領域を設定できるという本発明の特徴について説明する。予約した領域であることを示すために、第１、第２のビットマップテーブルともにブロックに対応したプリアロケーテッドフラグを持ち、このフラグがセットされていると、対応する基本ブロックまたはサブブロックが予約領域であることがわかる。従って、別なプロセスが同じ記録媒体を共有して使用している場合であっても、別なプロセスが予約領域を使用することがない。
【０１１８】
また、予約領域は一種の特別なファイル（予約領域ファイルと呼ぶことにする）として登録し、その管理情報にそこに記録するファイルの識別情報（ファイルシステムが使用するファイルの識別番号、あるいはファイル名など）を格納できるようにしておくと、その予約領域がどのファイルの記録のために予約してあるのか判断できる。この管理情報は、領域予約時に指定してもよいし、予約時には単に領域だけ確保し、実際に記録する段階で記録するファイルの識別子をセットしてもよい。
【０１１９】
また、予約領域ファイルは他の通常ファイルと区別できるように、その管理情報として予約領域ファイルであることを示す識別情報をもつようにする。予約領域はファイルとして管理するようにしたので、複数の予約領域を区別して管理することができる。また、予約した領域は予約領域ファイルとして参照できるので、予約する時点ではそこに記録するデータを特定せず領域の確保だけを行い、後で実際にデータを記録する際に、既にある予約領域ファイルを参照することによって確保した予約領域を利用することができる。
【０１２０】
また、予約領域に記録するファイルの管理情報には、予約領域ファイルを特定するための識別情報を格納できるようにする。これによって、予約領域ファイルとそこに記録するファイルの間で相互に参照できるようになる。
【０１２１】
あるファイルにおいて予約領域をセットして記録する場合、基本ブロック単位に記録するファイルの場合は、基本ブロック単位に予約領域を確保し、サブブロック単位に記録するファイルの場合は、サブブロック単位に予約領域を確保する。予約領域のサイズは、予約領域を確保する際に同時に指定するようにする。
【０１２２】
あるいは、指定したサイズが基本ブロックより大きいか小さいかによってどの単位で予約領域を確保するかを決めてもよい。例えば、指定したサイズが基本ブロックより大きい場合には基本ブロック単位の予約領域とし、小さい場合はサブブロック単位の予約領域としてもよい。この時、予約したブロックに対応するプリアロケーテッドフラグを予約領域としてセットする。
【０１２３】
予約領域にデータを記録中に予約領域が足りなくなりそうな場合、予約領域の残りサイズが予め定めた量以下になると、予約領域を拡張する。予約領域を拡張する場合、拡張するサイズは予め定めたサイズ、または予約領域に作成時に決定したサイズ、または予約領域に記録するファイルをオープンした時点で決定したサイズのいずれかで拡張するものとし、そのサイズは基本ブロックまたはサブブロックの倍数とする。
【０１２４】
拡張する予約領域は、現在の予約領域の直後以降で利用可能な最初の基本ブロックまたはサブブロックから確保する。従って、基本ブロック単位で拡張する場合は、第１のビットマップテーブルを検索して、予約領域より後の利用可能な最初の基本ブロックを探す。
【０１２５】
サブブロック単位で拡張する場合は、予約領域が所属するサブブロックの第２のビットマップテーブル内に予約領域より後の利用可能なサブブロックがあるかを検索し、そこにない場合、あるいはそれでは不足する場合、次に利用可能な基本ブロックを第１のビットマップテーブルから検索し、そこをサブブロックに分割した上で先頭から順に予約領域として確保するか、サブブロックに分割した基本ブロックを第１のビットマップテーブルから探し、その中で利用可能な最初のサブブロックを探して確保する。
【０１２６】
もし、確保した領域よりも後に新たに確保する領域が見つからない場合は、媒体の先頭に戻って、空き領域を探す。予約領域ファイルは、後で予約領域を追加する場合の追加領域サイズを管理情報として持つことができる。追加領域サイズがない場合、あるいは特に指定しない場合は、基本ブロックまたはサブブロックの数倍のあらかじめ定めた単位で拡張するようにする。
【０１２７】
このように、本実施の形態では、予約領域にデータを記録している際に、予約領域が不足した場合、適切なサイズで予約領域を拡張できるようにしたので、最初の予約領域サイズが不充分であっても、外部フラグメンテーションの発生を最小限に抑えながら、動的に対応できる。
【０１２８】
他方、予約領域が余った場合、余った領域をそのまま残しておいてもよいし、解放してもよい。どちらにするかは、予め予約領域を作成する時点、あるいは、予約領域への記録を開始する時点で決めてもよいし、記録するファイルをクローズする時点で決めてもよい。
【０１２９】
解放する場合は、ビットマップ上のプリアロケーテッドフラグをリセットし、予約領域ファイルを削除する。そのまま残す場合は、ビットマップ上のプリアロケーテッドフラグと予約領域ファイルを残ったエリアに対応するように修正する。残った予約領域を利用して前記ファイルに追加書きこみをする場合は、前記ファイルには前記予約領域ファイルの識別情報があるので、これを参照することによって直ちに記録する場所の情報を取得できる。
【０１３０】
このように、本実施の形態では、予約領域にデータを記録している際に、記録終了時に予約領域が余った場合、その領域をそのまま予約領域として残しておくか、あるいは解放するかを、指定することができるので、例えば後から追加記録する可能性が大きい場合は、将来の記録に備えてそのまま予約領域を残し、追加記録する可能性が低い場合は、予約領域を開放して、媒体の空き領域を増やすような運用ができる。
【０１３１】
次に、本発明のＡＶストリームへの適用例として、ＭＰＥＧ２のトランスポートストリーム（ＴＳ）とプログラムストリーム（ＰＳ）の両方に適用可能な実施の形態について説明する。
【０１３２】
ＴＳは主に放送系に使用される１８８バイトのパケットサイズのストリームである。ＴＳはパケットの到着時刻によってデコーダのシステムクロックを管理するので、ＴＳパケットを記録する場合は、到着時刻におけるシステムのカウンタの値をタイムスタンプとしてパケットに付加して記録する方法がＤＶＨＳ等で一般に行われている。タイムスタンプやその他の付加情報を含めたパケットサイズは一般に１９２バイトである。
【０１３３】
一方、ＰＳは主にＤＶＤ等の蓄積系に使用され、パケットサイズは可変であるが、ＤＶＤの場合、光ディスクのセクタサイズ（２０４８バイト）との親和性から２０４８バイトが一般に使用される。このサイズはＨＤＤで一般に用いられるセクタサイズ５１２バイトの整数倍（４倍）であるため、ＨＤＤとも同様に親和性がよい。すなわち、光ディスクには１セクタに１パケット記録可能で、ＨＤＤには４セクタに１パケットを記録可能である。ＨＤＤの場合は４セクタをセットで扱うことによって容易に１パケットを扱うことが可能である。
【０１３４】
これに対し、ＴＳは１９２＝２６×３より、因数に３を含んでいるため、ＨＤＤや光ディスクにＴＳパケットを記録すると、パケットが２つのセクタにまたがる個所が発生する。一つのパケットは連続して記録再生することが望ましいが、一般にはパケットが分割される場所で外部フラグメンテーションが発生する可能性がある。
【０１３５】
例えば、ＦＡＴファイルシステムでは、連続しないクラスタにまたがってパケットが配置される可能性がある。ＦＡＴファイルシステム以外のファイルシステム、例えば光ディスクに用いられるＵＤＦ（Universal Disk Format）などではクラスタという概念は無く、ディスク上の連続セクタ領域（エクステント）毎に記録しており、各エクステントのサイズには制約がないため、エクステントの境界で、パケットの分割が発生する可能性がある。
【０１３６】
これを避けるためには、ＰＳの場合は１個のパケットを複数個の連続するセクタで記録し、ＴＳの場合は複数個の連続するパケットを複数個の連続するセクタで記録するための制約を与える必要がある。
【０１３７】
そこで、ＴＳとＰＳで一般的に用いられるパケットサイズ１９２バイトと２０４８バイトの最小公倍数である６１４４バイト（＝６ｋバイト；１ｋバイトは１０２４バイト）の倍数を基本ブロックのサイズとすると、ＴＳ、ＰＳいずれのパケットを記録する場合でもパケットが２つの基本ブロックをまたがることがないので、基本ブロック単位の外部フラグメンテーションが発生しても問題ない。
【０１３８】
次に、配置されたデータ（ファイル）を配置方法に関わり無く、共通の構造で管理する方法について説明する。前述したように、２種類のブロックサイズ（すなわち、基本ブロックとサブブロックの各ブロックサイズ）に応じた２種類のビットマップテーブルを持つことは、これによって記録媒体の使用状況を効率良く検索できるので、特に記録時に必要なブロックサイズの空き領域を素早く取得するのに有効である。以下では、再生時のファイルへのアクセス方法について説明する。
【０１３９】
本発明では、基本ブロックに格納されたファイルであっても、サブブロックに格納されたファイルであっても、あるいは、両者をどのように組み合わせて格納されたファイルであっても、同一の形式、手続きでアクセスすることができるため、サブブロックに格納されたファイルへのアクセスが不利になることはない。
【０１４０】
このため、本発明では、媒体上のデータを連続するセクタに配置されたデータの塊の集合として扱っている。このデータの一塊のことを一般にエクステントと呼び、一般に用いられているデータの管理形式の一つである。
【０１４１】
図６は本発明におけるファイル管理情報の一例を示す。ファイル管理情報は、ファイル本体と１対１に対応する一種のファイルである。同図において、ファイル・インフォメーション・ブロック・デスクリプタ（File_Information_Block_Descriptor）は、ファイル管理情報であることを示す識別子の他、ファイル管理情報全体のサイズなどの情報が格納されている。
【０１４２】
また、ファイル・インフォメーション（Ｆｉｌｅ＿Ｉｎｆｏｒｍａｔｉｏｎ）は、ファイル名、タイムスタンプ、アクセス属性などの各種属性、ファイルサイズ等が格納される。また、ナンバーオブエクステント（Ｎｕｍｂｅｒ＿ｏｆ＿Ｅｘｔｅｎｔ：ＮＥ）はエクステントの数、ファイルエクステント（Ｆｉｌｅ＿Ｅｘｔｅｎｔ）はＮＥ個のエクステントの並びである。
【０１４３】
エクステントの表現形式はいろいろあるが、基本的にはエクステント先頭データの媒体上のアドレスと、エクステントのサイズの組み合わせで表す。本発明の一実施の形態では、エクステントの先頭アドレスとしてパーティション先頭からの論理ブロックアドレスを用いているが、論理セクタアドレス等、媒体上の位置を特定できるアドレス情報であれば何を用いてもよい。また、エクステントサイズは、論理ブロック単位に丸めた値を用いているが、実際に使用しているバイト数を用いてもよい。論理ブロック単位に丸めた値を用いる場合は、ファイル・インフォメーションに格納されたファイルサイズから正確なバイト数を得ることができる。
【０１４４】
図７は本発明になる記録媒体の一実施の形態の記録情報の説明図を示す。同図において、記録媒体は同一サイズの基本ブロック毎に論理的に分割されており、データ領域の先頭から昇順に識別番号が割り当てられている。図７はその一部を取り出した例で、丸数字で示す４から１７までの基本ブロックと、その一部の拡大図を示している。基本ブロックのうち、丸数字の１３と１６はどちらも１２個の同一サイズのサブブロックに分割してある。
【０１４５】
なお、サブブロック数は１２個以外の数であってもよく、また基本ブロック毎に違う数であってもよい。また、サブブロックの取り扱いを容易にするために、基本ブロック内をすべて等サイズのサブブロックに分割することが望ましいが、基本ブロック内の最終ブロックのサイズが異なることを禁止するものではない。
識別情報としては、基本ブロックの位置が特定できれば十分であり、上記のように基本ブロック毎に昇順につけられた識別番号を利用する場合は、基本ブロックのサイズと識別番号の積で、基本ブロックの開始位置が特定できる。基本ブロックの開始セクタアドレスと終了セクタアドレス（またはサイズ）を直接用いれば計算しなくても直ちに位置を特定できる。
【０１４６】
また、図７において、ファイルａとファイルｂは基本ブロック単位に記録した大きいサイズのデータである。このうち、ファイルａは３つの連続する基本ブロック（丸数字５、６、７）に配置されているため、１つのエクステントＥａ１で構成されているが、ファイルｂは２つのエクステントＥｂ１とＥｂ２に分かれており、ここで基本ブロック単位の外部フラグメンテーションが発生している。なお、ファイルｂの最終部分は、領域を有効活用するためにサブブロックに分割されている。
【０１４７】
ファイルｃとファイルｄは、サブブロック単位に記録した小さいサイズのデータである。ファイルｃは丸数字１３で示す基本ブロック中のサブブロックの識別番号７〜９の３つの連続するサブブロックに配置されているため、１つのエクステントＥｃ１で構成されている。これに対し、ファイルｄは丸数字１６で示す基本ブロック中の識別番号０〜３までの連続するサブブロックからなるエクステントＥｄ１と、識別番号７と８のサブブロックからなるエクステントＥｄ２の計２つのエクステントに分かれて配置されているため、ここでサブブロック単位の外部フラグメンテーションが発生している。以上をまとめると、表１に示すようになる。
【０１４８】
【表１】
【０１４９】
なお、図７の例では説明のためにファイルを分割して媒体上にばらばらに配置したが、通常の使用時に空き領域がある場合は、できるだけ連続する領域に配置するように運用する。
【０１５０】
一つのファイルの配置情報はエクステントによって管理する。ファイルが媒体上で複数のエクステントに分かれている場合は、エクステント情報の並び（リスト）によって、その配置状態を表す。エクステントの情報は、エクステント先頭データの媒体上のアドレスと、エクステントのサイズの組み合わせで表す。一般に媒体へのアクセスは論理ブロック単位で行われるため、ファイルの先頭は論理ブロックの先頭から配置される。
【０１５１】
従って、通常、前記アドレスは論理ブロックアドレスなどのブロック単位のアドレスで表記される。また、サイズについても同じ理由から論理ブロック単位で指定されることが多い。論理ブロックのサイズは媒体によって異なり、一般にＨＤＤやメモリデバイス等では５１２バイト、光ディスク系では２０４８バイトが用いられる。実際のデータサイズは、論理ブロック以下の端数がでるため、最終論理ブロックについては、ファイル全体のサイズから有効データサイズを取得する。エクステントのサイズとしてバイト単位で指定するようにした場合は、全体のサイズ情報が無くても直接有効なデータサイズを取得することができる。
【０１５２】
図７において、４つのファイルａ〜ｄの配置情報を取り出してまとめると、表２に示すようになる。
【０１５３】
【表２】
表２において、Ｓ＊（＝Ｓａ、Ｓｂ、Ｓｃ、Ｓｄ）はそれぞれファイルａ、ｂ、ｃ、ｄのファイルサイズ、Ｎ＊（＝Ｎａ、Ｎｂ、Ｎｃ、Ｎｄ）はエクステントの数、（Ａ＊，Ｅ＊）は１つのエクステント情報であり、Ａがエクステントの先頭論理ブロックアドレスを示し、Ｅがエクステントの論理ブロック単位のサイズを示す。＊はファイルの識別用に便宜的に付加したもので、ａ、ｂ、ｃ、ｄはそれぞれのファイルａ、ｂ、ｃ、ｄに対応する。数字はエクステントの番号である。
【０１５４】
図６と対応付けると、Ｓ＊はファイル・インフォメーション（Ｆｉｌｅ＿Ｉｎｆｏｒｍａｔｉｏｎ）内に格納される情報、Ｎ＊はナンバーオブエクステント（Ｎｕｍｂｅｒ＿ｏｆ＿Ｅｘｔｅｎｔ：ＮＥ）、（Ａ＊，Ｅ＊）はファイル・エクステント（Ｆｉｌｅ＿Ｅｘｔｅｎｔ）［ＮＥ］である。
【０１５５】
図６の別な例として、Ｆｉｌｅ＿Ｅｘｔｅｎｔ［ＮＥ］の最後の要素の後に、最後のエクステントであることを示すターミネイト識別子を置いてもよい。この場合、ナンバーオブエクステントがなくてもすべてのエクステントがわかるので、ナンバーオブエクステントを省略してもよい。また、ファイル・インフォメーション・ブロック・デスクリプタ内に、この管理情報全体のサイズを格納しておけば、ナンバーオブエクステントも前記ターミネイト識別子も省略することができる。あるいは、すべての情報を省略することなく格納することで、管理情報全体の信頼性を向上させることもできる。
【０１５６】
ターミネイト識別子を置く場合、通常のエクステント情報と同じ構造で、通常のエクステントと区別できるものを予め決めておけば何でもよい。例えば、エクステントのサイズが０のエクステントは存在しないので、Ｅ＊＝０のエクステント情報をターミネイト識別子とすることができる。あるいは、エクステント情報毎にフラグを用意して、最終エクステントかどうかを明示してもよい。
【０１５７】
このように、ファイルの配置情報は、ファイルの配置場所に関わり無く同じ形式で表現されるため、基本ブロックに配置されたファイルでも、サブブロックに配置されたファイルでも同じ手続きでアクセスすることができるため、どちらかのアクセス効率が不利になることはない。また再生時は、前記エクステント情報だけを用いてファイルの配置情報を取得でき、ビットマップテーブルを参照する必要はない。
【０１５８】
次に、配置済みのファイルが実際にどのように２つのビットマップテーブルで表現されているかを、図７の例を使って説明する。図８は図７に対応する第１のビットマップテーブルの例である。この例では、ブロックの状態を表す管理情報として、図３に示した例のうち、スケール（ｓｃａｌｅ）とユーザブル（ｕｓａｂｌｅ）の２ビットだけを用いた。この２ビットは第１のビットマップテーブルを構成するための最低必要な要素である。
【０１５９】
図８は各ブロックに対応する各フラグがどの状態になっているか分かり易いようにテーブルで表現してある。ｓｃａｌｅフラグは１の時に基本ブロック単体として使用していることを示し、０の時にサブブロックに分割してあることを示す。従って、図８のｓｃａｌｅフラグより、図７に丸数字１３と１６で示した２つの基本ブロックがサブブロックに分割してあることがわかる。また、図８のｕｓａｂｌｅフラグは、ｓｃａｌｅフラグに対応する未使用のブロックがあるかどうか（使用可能かどうか）を示すフラグであって、１のときｓｃａｌｅフラグに対応した未使用のブロックがあることを示す。
【０１６０】
従って、例えば、ブロック４は基本ブロックとして割り当ててあり１バイトも使用していない。ブロック５は基本ブロックとして使用中であることを示している。また、図７では、ブロック７は基本ブロックとして使用しており、まだ空き領域はあるが、この部分はもう基本ブロックとしては新たに使用できない（既にあるデータへの追記録しかできない）ので、ブロック５と同じように扱われる（ｕｓａｂｌｅ＝０）。
【０１６１】
一方、ブロック１３は基本ブロックに割り当てられたファイルｂの最終部分が格納されるブロックであるが、ブロック７と異なりサブブロックに分割してある。図７の拡大図を見ると、この部分はサブブロックの先頭の３ブロックしか使用していないため、ブロック７と異なり残りの９個のサブブロックを他のデータの記録用に使用することができる。
【０１６２】
図７の例では、実際にサイズＳｃのファイルｃを基本ブロック１３の中の７、８及び９番目のサブブロックに記録している。ファイルｃを記録した後でも、基本ブロック１３の中の３〜６番目と１０、１１番目のサブブロックは未使用なので、サブブロックとして利用可能なブロックが存在する（ｕｓａｂｌｅ＝１）。
【０１６３】
図９はサブブロックに分割した基本ブロック１３の第２のビットマップテーブル（ビットマップ本体のみ）を示す。図７に示したように、基本ブロック１３は、サブブロック０、１、２がファイルｂの最終部分によって使用され、サブブロック７、８、９がファイルｃによって使用されているので、図９に示す第２のビットマップテーブルは、サブブロック０、１、２、７、８、９が使用されていることを、ｕｓａｂｌｅ＝０で示している。
【０１６４】
図９ではサブブロックの状態を管理するフラグとしてはｕｓａｂｌｅの１ビットだけを示した。この１ビットが第２のビットマップテーブルを構成するための最低必要な要素である。同様に、図１０には基本ブロック１６の第２のビットマップテーブルを示す。図７では、基本ブロック１６は、サブブロック０〜３がファイルｄの１番目のエクステントＥｄ１によって使用され、サブブロック７、８がファイルｄの２番目のエクステントＥｄ２によって使用されているので、図１０に示す基本ブロック１６の第２ビットマップテーブルでは、サブブロック０〜３、７及び８が使用されていることを、ｕｓａｂｌｅ＝０で示している。
【０１６５】
ビットマップデータの実際のデータは、ブロック毎のフラグをブロック番号順に並べて求める。図１１は第１のビットマップのデータの求め方を示している。ブロック毎に（ｂｉｔ１，ｂｉｔ０）＝（ｕｓａｂｌｅ，ｓｃａｌｅ）とフラグを並べ、これを１バイトの中でＬＳＢ側からブロック順に詰めていってデータを作成する。図１１ではバイト内でブロック順に詰める操作は、左側をＭＳＢにしているため並べ替え操作になる。
【０１６６】
＃を１６進数を表すものとすると、最終的なデータは、順に♯ＦＦ，♯５７，♯ＤＦ，♯Ｆ９，♯ＦＥ，・・・となる。第２のビットマップテーブルも同様に求めると、ブロック１３は、♯７８，♯ＦＣ、ブロック１６は♯７０，♯ＦＥとなる。なお、２バイト目は下位４ビットのみ有効である。この例ではサブブロックは１２に分割してあり、管理情報のフラグがブロックにつき１ビットしかないので基本ブロック１つにつき１２ビットのテーブルサイズになる。
【０１６７】
図１２は基本ブロック１３、１６のビットマップデータを取得する手順を示す。図６に示したフィル管理情報内の情報の１つであるファイルインフォメーション（Ｆｉｌｅ＿Ｉｎｆｏｒｍａｔｉｏｎ）には、前記ファイルサイズ以外にもいくつかの情報がある。図１３は、このファイルインフォメーションの一例である。同図において、ファイルＩＤ（Ｆｉｌｅ＿ＩＤ）は、パーティション内でファイルまたはディレクトリに固有な識別番号である。本発明におけるファイルシステムは、ディレクトリはそのデータ構造が予め規定されたファイルとして扱うので、デイリクトリにもＦｉｌｅ＿ＩＤがある。
【０１６８】
ルートディレクトリのＦｉｌｅ＿ＩＤは予め定めた特定の値、例えば０に予約されているものとする。ルートディレクトリを初めとする、すべてのディレクトリには、そのディレクトリに所属するファイル又はディレクトリのＦｉｌｅ＿ＩＤが格納されているので、ルートディレクトリ以下の階層構造を、ディレクトリの内容を辿ることによって取得できる。
【０１６９】
また、図１３中、ディレクトリＩＤ（Ｄｉｒｅｃｔｏｒｙ＿ＩＤ）は、このファイルまたはディレクトリが所属しているディレクトリのＦｉｌｅ＿ＩＤを格納する。この情報を参照することによって、下位のディレクトリ階層にあるファイルからルートディレクトリまで逆に辿ることができる構造になっている。
【０１７０】
また、ターゲットＩＤ（Ｔａｒｇｅｔ＿ＩＤ）は、このファイルが予約領域ファイルである場合、この予約領域に記録するファイルのＦｉｌｅ＿ＩＤを格納する。また、このファイルが予約領域に記録する通常ファイルである場合、予約領域ファイルのＦｉｌｅ＿ＩＤを格納する。
【０１７１】
また、ファイルフラグ（Ｆｉｌｅ＿Ｆｌａｇｓ）は、後述するファイルの各種属性を表すフラグ群である。タイムスタンプ（Ｔｉｍｅ＿Ｓｔａｍｐ）は、このファイルに関する各種時刻情報であり、作成日時、最終更新日時、最終アクセス日時、削除した日時などを格納する。ファイルサイズ（Ｆｉｌｅ＿Ｓｉｚｅ）は前記ファイルサイズである。更に、ファイルネーム（Ｆｉｌｅ＿Ｎａｍｅ）は、このファイルを参照するための名称である。キャラクタコードやサイズについては本発明では特に規定しない。
【０１７２】
上記のＦｉｌｅ＿Ｆｌａｇｓには、少なくとも表３に示す３つのフラグを持つ。すなわち、バリッド（Ｖａｌｉｄ）、デリーテッドファイル（Deleted File）及びプリアロケーテッド・エリア（Preallocated Area）である。
【０１７３】
【表３】
このほか、本発明では触れないが、ファイルの所有者やグループに対する、可視属性、書きこみ属性、実効属性などの各種ファイル属性などを持つ。
【０１７４】
表３に示したバリッドフラグは通常１で、そのファイルまたはディレクトリが有効であることを示す。あるファイルを消去する場合は、通常、そのエントリに対するファイル管理情報を完全に消去すると同時に、ビットマップテーブルで該当ファイルが占める領域を空き領域に変更する必要があるが、本発明では、ファイル管理情報を削除する際に、そのエントリを完全に消去してしまう以外の方法として、前記バリッドフラグを０にすることによって、この管理情報が無効であることを表すようにしている。これによって、管理情報のサイズが大きかった場合でも、前記フラグだけを０にすればよいので、ファイルの消去が容易に行える。
【０１７５】
また、ファイルを削除した後で削除を取り消したい場合があるので、表３に示したデリーテッドファイルというフラグをファイル管理情報に設け、一時削除／復活に対応できるようにした。すなわち、デリーテッドファイルが１の時は通常の状態のファイルだが、０にセットすることによって、このファイルが一時削除状態にあることを示す。
【０１７６】
一時削除状態にある場合は、このファイルに対するアクセスは禁止され、通常の手段では、その存在も見えないようにしておく。一時削除ファイルがあるかどうかは、専用のアクセス手段によってその存在が見えるようにしておき、専用の手段によって復活できるようにしておく。一時削除ファイルにアクセスしたい場合は、前記専用の手段によって、通常のファイルに復活してからアクセスするものとする。
【０１７７】
一時削除中のファイルは、それが占めている媒体上の記録スペースを他のファイルによって上書きされないように、その配置情報はそのまま保っておく必要がある。これは単に、第１と第２のビットマップテーブルを、一時削除前の状態のまま変更しないだけでよい。すなわち、一時削除前と後では、前記デリーテッドファイルフラグだけが変更されている。
【０１７８】
フラグを用いて永久に削除する場合の違いは、永久に削除する場合は、バリッドフラグの変更のほかに、ビットマップテーブルのファイル占有領域を開放する点である。永久削除を意味するバリッドフラグを用意することにより、エントリを完全に消去しなくてもこのバリッドフラグをクリアするだけで永久削除と同じ効果が得られ、高速な消去が可能である。
【０１７９】
なお、バリッドフラグを用いた削除の場合でも、削除した直後など、データが上書きされていない場合には、専用の手段を設ければファイルを復活することも可能である。
【０１８０】
プリアロケーテッド・エリアフラグは、このファイルが予約領域ファイルであることを示す。予約領域ファイルは、特定のファイルあるいは、将来何らかのファイルを記録するために予め記録する領域を確保するために設けられた特別なファイルである。プリアロケーテッド・エリアフラグは通常ファイルの場合は０で予約領域ファイルの時に１に設定する。
【０１８１】
予約領域ファイルの配置された領域は予約領域そのものであり、予約領域ファイル自体はデータをもたないため、予約領域ファイル自体はデータを書き込まない。予約領域に書き込むファイルが決まったら、そのファイルＩＤ（Ｆｉｌｅ＿ＩＤ）を、図１３のターゲットＩＤに格納し、予約領域ファイルの先頭からファイルデータの記録を開始する。
【０１８２】
予約領域ファイルの作成は、実際に書き込むファイルをオープンする直前に行ってもよく、この場合は、予約領域ファイルの作成と同時にターゲットＩＤに記録するファイルのファイルＩＤを書き込んでおく。これは、ファイルを書き込みオープンするときに、予約領域サイズを指定してオープンする専用の手続きによって実現することができる。また、予約領域に書き込むファイルのターゲットＩＤには、予約領域ファイルのファイルＩＤを格納し、両者が相互に参照できるようにする。
【０１８３】
予約領域ファイルが占有する領域は、ビットマップテーブル上では、図３のプリアロケーテッドフラグで示され、基本ブロックまたはサブブロック単位で予約領域かどうかを調べることができる。複数の予約領域ファイルや複数の一時削除ファイルを管理するために、例えばルートディレクトリの直下に専用のディレクトリを設け、このディレクトリ内でこれらのファイルを管理すると効率良く管理することができる。
【０１８４】
図１４はディレクトリ内でファイルを管理する一例の説明図を示す。同図において、ルートディレクトリの直下に「ｐｒｅａｌｌｏｃ．ｄｉｒ」という予約領域ファイルを配置する専用のディレクトリがある。このディレクトリには「ａｒｅａ１．ｄａｔ」、「ａｒｅａ２．ｄａｔ」という２つの予約領域ファイルがある。これらはそれぞれ、／ａｖｄａｔａ．ｄｉｒ／ｓａｍｐｌｅ．ｄｉｒ／ａ．ｄｉｒというディレクトリにある「ａ１．ｄａｔ」と／ａｖｄａｔａ．ｄｉｒ／ｓａｍｐｌｅ．ｄｉｒ／ｂ．ｄｉｒというディレクトリにある「ｂ１．ｄａｔ」というファイルに対応している。
【０１８５】
すなわち、「ａｒｅａ１．ｄａｔ」は予約領域ファイルであることを示す、プリアロケーテッド・エリアフラグが１にセットされ、ターゲットＩＤとして、／ａｖｄａｔａ．ｄｉｒ／ｓａｍｐｌｅ．ｄｉｒ／ａ．ｄｉｒ／ａ１．ｄａｔを特定するための情報が格納されており、「ａ１．ｄａｔ」には「ａｒｅａ１．ｄａｔ」を特定するための情報が格納されている。
【０１８６】
また、「ａｒｅａ２．ｄａｔ」は予約領域ファイルであることを示す、プリアロケーテッド・エリアフラグが１にセットされ、ターゲットＩＤとして、／ａｖｄａｔａ．ｄｉｒ／ｓａｍｐｌｅ．ｄｉｒ／ｂ．ｄｉｒ／ｂ１．ｄａｔを特定するための情報が格納されており、「ｂ１．ｄａｔ」には「ａｒｅａ２．ｄａｔ」を特定するための情報が格納されている。
【０１８７】
一般に、階層ディレクトリ精造を持つファイルシステムでは、ファイルはディレクトリの木構造の中で分散してしまうため、それぞれのファイルが予約領域を持つ場合、予約領域の一元管理が難しい。本発明では、予約領域を予約領域ファイルに対応付けることによって複数の予約領域を区別して管理でき、さらにこれを１つのディレクトリでまとめて管理できるようにしたので効率の良い管理が可能になった。
【０１８８】
また、図１４において、「ｄｅｌｆｉｌｅｓ．ｄａｔ」は、一時削除したファイルを特定するための情報をテーブルとして持ち、／ａｖｄａｔａ、ｄｉｒ／２００１．０２．０１．ｄｉｒディレクトリにある、「ｆｉｌｅ２．ｄａｔ」と「ｆｉｌｅ３．ｄａｔ」に関する識別情報が記録されている。「ｆｉｌｅ２．ｄａｔ」と「ｆｉｌｅ３．ｄａｔ」はデリーテッドファイルフラグが０になっており、一時削除状態にある。従って、通常の手続きで／ａｖｄａｔａ．ｄｉｒ／２００１．０２．０１．ｄｉｒディレクトリを見ると、「ｆｉｌｅ１．ｄａｔ」しか見えない。
【０１８９】
なお、この例では、「ｄｅｌｆｉｌｅｓ．ｄａｔ」は／ｄｅｌｅｔｅｄ．ｄｉｒというディレクトリにおいたが、他のディレクトリやルートディレクトリにおいてもよい。例えば、ディレクトリ毎に置くようにして、そのディレクトリ内の一時ファイルのみを管理するようにしてもよい。
【０１９０】
本発明では、このように一時削除ファイルをまとめて管理できるようにしたので、復活したいファイルを検索し、一時削除ファイルを永久に削除することによって記録領域を増やしたい場合など、簡単に一時ファイルを参照することができて都合がよい。
【０１９１】
一時削除したファイルを特定する識別情報のテーブルは、ディレクトリ毎に持ってもよい。図１４の例では、／ａｖｄａｔａ．ｄｉｒ／２００１．０２．０１．ｄｉｒに「ｄｅｌｆｉｌｅｓ．ｄａｔ」をおけばよい。
【０１９２】
着目しているディレクトリ内の一時削除ファイル情報を取得する場合、パーティション全体の一時削除ファイルのリストでは、一つ一つ該当ディレクトリのファイルかどうかをチェックする必要があるが、ディレクトリ毎に一時削除ファイル情報を用意しておけば、これを参照することによって直ちに取得することができる。なお、全体の一時削除ファイルとディレクトリ毎の削除ファイルが両方あってももちろんよい。
【０１９３】
次に、ビットマップテーブルのアラインメントについて説明する。
図１５は第１のビットマップテーブルの記録媒体上の配置例を示す。第１のビットマップテーブル１５１は、その管理情報１５２とテーブル本体１５３から構成される。媒体上に記録する場合は、論理セクタ単位でアラインメントが取れるように、管理情報１５２の直後、またはテーブル本体１５３の直後にスタッフィングのためのダミーデータ１５４を挿入する。
【０１９４】
次に、第２のビットマップテーブルの記録媒体上の配置例について図１６及び図１７と共に説明する。第２のビットマップテーブルは、第１のビットマップテーブルよりサイズが小さく、複数個存在し、その数が使用時に変動するという特徴がある。
【０１９５】
図１６は、１つの第２のビットマップテーブルサイズが論理セクタサイズよりも大きい場合の例であり、第１のビットマップテーブルと同様に第２のビットマップテーブル毎に論理セクタ単位でアラインメントをとるためのダミーデータを付加している。
【０１９６】
また、各ビットマップテーブルは図１６（ａ）に示したように１個１個ばらばらに置いてもよいが、論理セクタ単位のアラインメントをとっているので、同図（ｂ）に示したように隙間無く詰めて配置することができる。この時、第１のビットマップテーブルでの配置の順番に従って第２のビットマップテーブルを順番に並べればサブブロックをまとめて管理するのに都合がよい。
【０１９７】
図１７は、第２のビットマップテーブルのサイズが論理セクタサイズより小さい場合の例で、（ａ）はその数が多くて合計のサイズが論理セクタサイズを超える場合、（ｂ）はその数が少なくて、合計サイズが論理セクタサイズに満たない場合の例である。図１７（ａ）、（ｂ）のどちらの場合も複数個のビットマップテーブルを隙間無く詰めて配置しているが、その際に各ビットマップテーブルが２のべき乗の倍数のバイト数になるようにしておくと、アドレッシングが容易になる。特に２のべき乗の同一サイズに設定すれば、ｎ個目のビットマップテーブルの位置をビットシフト演算だけで求めることができて効率が良い。
【０１９８】
次に、スタッフィングのためのダミーデータの配置方法について、図１８及び図１９と共に説明する。図１８のビットマップテーブルの管理情報１８１には、図４と図５で説明したように先頭のデスクリプタ（Descriptor）の中にビットマップテーブル全体のサイズ１８４が格納されている。また、ビットマップテーブル本体１８２のサイズも同様に格納されている。管理情報部分のサイズは固定なので、ビットマップテーブル本体１８２の後にダミーデータ１８３を付加し、全体のサイズにダミーデータ１８３を含めたサイズを格納すればよい。
【０１９９】
あるいは、管理情報を可変長とし、図１９に１９３で示すように管理情報内に管理情報部分のサイズを格納することにより、管理情報本体１９１の直後にダミーデータ１９２を付加することもできる。このようにすると、ビットマップテーブルの開始アドレスを都合のよい値に設定することができる。
【０２００】
図１８と図１９の方法は組み合わせてもよく、この場合、ビットマップテーブルの開始アドレスを任意の値に設定すると同時に、ビットマップテーブルの全体サイズを論理セクタの倍数に設定することが可能になる。
【０２０１】
次に、ＦＡＴファイルシステムとのブリッジについて説明する。図２０は、ＦＡＴ１２またはＦＡＴ１６ファイルシステムとのブリッジの例を示す。同図において、ＦＡＴファイルシステムのデータ領域はルート（ＲＯＯＴ）ディレクトリの直後以降であり、ファイルシステム＃１のデータ領域もここから始まる。ＦＡＴファイルシステムの先頭クラスタ番号は”２”であり、以後昇順にクラスタ番号が振られている。ファイルシステム＃１は６クラスタを１基本ブロックのサイズとしており、基本ブロック０から昇順に基本ブロックが割り当ててある。
【０２０２】
サブブロックのサイズはクラスタサイズと同じで、サブブロックに分割した基本ブロックについては、クラスタと同様に扱うことができる。同図で基本ブロック０、２、３がサブブロックに分割した基本ブロックである。
【０２０３】
同図では以下の４つの通常のファイルａ〜ｄと管理情報ファイルがあり、ファイルシステム＃１では図２１に示すようにファイル管理情報filectr1で管理されている。このファイル管理情報filectr1は、データ領域の任意の位置に配置できて、図２０では２０１に示すように、基本ブロック３のサブブロック３に格納されているものとする。また、第１のビットマップテーブルに続いて第２のビットマップテーブルが連続して配置され、これは基本ブロック３のサブブロック０に格納されている。なお、図２１の情報は、記録媒体に記録されている図６に示したファイル管理情報を再生することにより直接に得られてメモリに展開される。
【０２０４】
また、ファイルシステム＃１の全体を管理するためのシステム情報Ａ、ＢがＦＡＴファイルシステムのシステム領域の最後２０２、または基本ブロック３のサブブロック２５の領域２０３に配置されている。ここには、ボリューム全体の構造、このパーティションの構造、その他のシステム管理情報へのボインタ等が格納される。これらのデータ領域に配置された管理情報２０１は記録媒体であるディスク上の任意の位置に配置することができるので、記録領域にエラーが発生した場合などに、正常な領域に移動することができる。
【０２０５】
また、これらの管理情報は第２のファイルシステム（ここではＦＡＴファイルシステム）からファイルとして参照できるようになっている。図２２に、ＦＡＴファイルシステム上のファイル管理情報の１つであるディレクトリエントリから関係する情報だけを抜き出して示す。同図において、例えば、ファイルａはファイルサイズがＳａで、クラスタエントリ（ファイルの先頭データが格納されているクラスタ番号）ＣＥａが２であることを示す。つまり、ファイルａはクラスタ番号２番から格納されている。
【０２０６】
同様に、第１及び第２のビットマップテーブルは、ファイルサイズがＳｅで、クラスタエントリＣＥｅが２０であり、ファイル管理情報filectrlは、ファイルサイズがＳｆで、クラスタエントリＣＥｆが２３であり、ファイルシステム＃１のシステム情報sysctrlは、ファイルサイズがＳｇで、クラスタエントリＣＥｇが２５である。
【０２０７】
図２３は、ＦＡＴファイルシステムのもう一つのファイル管理情報であるＦＡＴの例である。同図では、３０個のクラスタエントリ（０〜２９）からなるＦＡＴを示すために、３行１０列の矩形領域で３０個のクラスタエントリを模式的に示している。例えば、ファイルａはクラスタ番号２、３、４に記録されているので、ディレクトリエントリにファイル名と一緒に最初に２番であるという情報が書かれる。また、図２３に示すように、ＦＡＴの２番のエントリを見ると、３と書かれているので、２番に続くデータがクラスタ番号３のクラスタに記録されていることが示されている。
【０２０８】
同様に、ＦＡＴの３番のエントリを見ると、４と書かれているので、３番に続くデータがクラスタ番号４のクラスタに記録されていることが示されており、更に、ＦＡＴの４番のエントリを見ると、Ｅと書かれているので、ファイルａのデータは、このクラスタ番号４番のクラスタで終了することが示されている。このようにして、記録媒体上のファイル配置を知ることができる。コンピュータは、図２２と図２３から抽出した各ファイルのクラスタ番号やクラスタサイズなどに基づいて、図２４に示すようなクラスタチェインを取得して、メモリ上に展開する。
【０２０９】
以上のように、ファイルシステム＃１からは、図２１の情報を介して、ＦＡＴファイルシステムからは図２４の情報を介して、同一のファイルにアクセスすることができる。
【０２１０】
また、ＦＡＴ３２ファイルシステムにおいては、ＲＯＯＴディレクトリが通常のデータ領域に置かれる。通常はデータ領域の先頭（クラスタ２）から配置されるが、必須条件ではないので、図２５に示すようにデータ領域の途中に配置してもよい。また、ＲＯＯＴディレクトリのサイズが足りなくなったら増やすことができるため、フラグメントが発生する場合もある。
【０２１１】
図２５に示すように、ＲＯＯＴディレクトリがデータ領域に配置される場合は、クラスタ単位で任意の位置に境界がくる可能性があるため、ＲＯＯＴディレクトリを含む基本ブロックでは、サブブロックに分割して使用することによって、余ったサブブロックの領域をデータ記録用に使用することができる。図２５では、ＲＯＯＴディレクトリを含む基本ブロック０、１をサブブロックに分割することによって、基本ブロック０のサブブロック０，１，２，３，４と基本ブロック１のサブブロック２，３，４，５を他のデータの記録に用いることができる。
【０２１２】
次に、ＮＴＦＳとのブリッジについて説明する。第２のファイルシステムとしてＮＴＦＳを用いる場合も、ＦＡＴ３２ファイルシステムと同様な構成にすることができる。このとき、ＭＦＴ（Master File Table）の扱いを、図２５に示したＲＯＯＴディレクトリの扱いと同じようにすればよい。
【０２１３】
次に、ＩＳＯ９６６０、ＵＤＦとのブリッジについて説明する。ＩＳＯ９６６０やＵＤＦは特定のセクタを起点として、記述子（descriptor）の集合として管理構造が配置され、各記述子にボリュームやファイルの構造が格納されている。
【０２１４】
ＩＳＯ９６６０では、図２６に示すようにボリューム記述子集合（ＶＤ）に続いてパステーブル（ＰＴ）が配置される。ＶＤにはボリューム構造に関する情報などが格納され、パステーブル（ＰＴ）にはすべての階層ディレクトリへのエントリが格納されている。これを参照することによって、ＲＯＯＴディレクトリから辿らなくても下位のディレクトリに直接アクセスすることが可能になっている。ファイルの配置情報自体は、前記第１のファイルシステムと同じエクステントによる形式であるため、ブリッジ構造をとることは、比較的容易である。
【０２１５】
図２７はＵＤＦの概要を示す図である。ＵＤＦでは、ボリューム構造に関する情報などはメイン・ボリューム・ディスクリプタ・シーケンス（ＭＶＤＳ：Main Volume Descriptor Sequence）中に格納される。ＭＶＤＳは、ポインタであるＡＶＤＰ（Anchor Volume Descriptor Pointer）によって参照される。
【０２１６】
ＭＶＤＳには、パーティションの位置やファイル集合記述子の場所などが格納されており、これを参照することによって、データエリアの場所とルートディレクトリの場所がわかる。ルートディレクトリにはファイル毎にＦＩＤというファイルの識別情報を示す記述子がある。
【０２１７】
ＦＩＤにはファイルの配置情報が直接記述してあるわけではなく、代わりにＩＣＢ（Information Control Block）と呼ばれる、ファイルのサイズ、配置、属性等の情報を記述したファイルを指している。実際のファイルへのアクセスはこのＩＣＢを通して間接的に行われる。これは、書換えを最小限にするために導入されたＵＤＦの特徴の一つである。ファイルに対する変更が行われると、これに対応するＩＣＢだけを変更すればよく、このファイルを含んだディレクトリの情報は書換える必要がないので、書換えの影響が上位のディレクトリに波及しないという特徴がある。
【０２１８】
以上のように、ＵＤＦの場合はファイル構造を管理するために、ファイル毎にＩＣＢというファイルが必要である。これらはファイルサイズが小さく、パーティション内の任意の位置に配置できるという特徴があるので、第１のファイルシステムと共存させる場合はこれらの管理情報をできるだけまとめて、サブブロックに分割した領域に配置するとよい。
【０２１９】
図２８は、第１のファイルシステムとＩＳＯ９６６０、ＵＤＦの３つのファイルシステムを共存させた本発明のブリッジファイルシステムの一実施の形態を示す。この実施の形態では、ルートディレクトリ以外のＩＣＢを一ケ所に集めてサブブロックに配置している。また、ＩＳＯ９６６０や、ＵＤＦにおけるファイル構造を管理するための情報である、ＰＴ（Path Table）や、ルートディレクトリ、ＩＣＢを含む基本ブロックはサブブロックに分割し、またサイズの小さいファイルもサブブロックに配置している。これらのＩＳＯ９６６０やＵＤＦの管理情報は、それぞれ又はいくつかをまとめて第１のファイルシステムからファイルとして参照することができる。
【０２２０】
同図において、基本ブロック０、１、２、４がサブブロックに分割した基本ブロックである。１つのサブブロックには、２個以上のファイルが入らないように運用する。ただし、ＩＣＢについてはサイズが小さく同じ形式のファイルであることから、同図に示したように、基本ブロック１のサブブロック０に連続して配置することによって、ファイルシステム＃１から見た場合は１つのファイルのように扱ってもよい。各ＩＣＢはＵＤＦから見るとたまたま連続して配置してあるだけであって、実際にはそれぞれ論理的に独立している。
【０２２１】
また、ファイルシステム＃１の管理情報であるビットマップテーブルは第１のビットマップテーブルに続いて第２のビットマップテーブルを連続して配置し、同図では、基本ブロック１のサブブロック２に配置されており、ファイルシステム１からもＵＤＦ、ＩＳＯ９６６０からも参照できる。同様に、ファイルシステム＃１のファイル管理情報が基本ブロック１のサブブロック３に、ファイルシステム＃１のシステム情報が基本ブロック１のサブブロック５に配置されており、どのファイルシステムからも参照できる。
【０２２２】
本発明は、記録領域のデータファイルに対し、第１と第２の両方のファイルシステムからアクセス可能にするブリッジファイルシステムであるが、すべてのデータファイルが両方のファイルシステムから参照できる必要はない。これは、他のファイルシステムからそのファイルに対してアクセスして欲しくない場合などに適用することができる。相互参照を行わないことによって、他のファイルシステムからはそのファイルの存在する隠蔽することができる。
【０２２３】
例えば、第１のファイルシステムからのみアクセスしたいファイルは、そのファイルの管理情報は第１のファイルシステムにのみ登録し、第２のファイルシステムには登録せず、その配置領域は少なくとも新たな記録には使用できないという情報を登録する。これによって、第２のファイルシステムがその領域を別なデータで上書きしてしまうことを避けることができる。逆の場合も同様である。
【０２２４】
データファイルだけでなく、ファイルシステムの管理情報についても相互に参照できるようにしてもよい。例えば、既に説明したように、第１のファイルシステムの管理情報を第２のファイルシステムからファイルとして参照できるだけでなく、第２のファイルシステムの管理情報を第１のファイルシステムからファイルとして参照できるようにすることもできる。
【０２２５】
管理情報を相互参照する場合、１つの管理情報を１つのファイルシステムに対応付けるのではなく、複数の管理情報をまとめて１つのファイルとして扱うようにしてもよい。管理情報についても、データファイルと同様に、相互参照が必須というわけではなく、参照する必要が無かったり、あるいは参照を禁止したい場合などは、特定の管理情報を相互参照できないようにしてもよい。
【０２２６】
【発明の効果】
以上説明したように、本発明によれば、以下の数々の特長を有する。
【０２２７】
（１）第１のファイルシステムを用意することで、リアルタイム記録再生が要求されるサイズの大きいＡＶストリームを基本ブロックに記録し、確実性が要求されるサイズの小さいＡＶストリームの管理情報などのファイルをサブブロックに記録するのに最適なファイルシステムを実現できる。
【０２２８】
（２）新しい第１のファイルシステムが搭載されていないコンピュータシステムにおいても、記録されたファイルにアクセスできるように、第２のファイルシステムを搭載して、第１及び第２のファイルシステムのどちらからもアクセスできるようにしたので、第２のファイルシステムとして、コンピュータシステムに標準的に搭載されているファイルシステムを採用すれば情報交換が容易にできる。
【０２２９】
（３）第２のファイルシステムとして、リムーバブルの記録媒体におけるデファクトスタンダードであるＦＡＴファイルシステムを採用したので、ほとんどすべてのコンピュータシステムで利用できる。
【０２３０】
（４）第２のファイルシステムとしてＮＴＦＳを採用したので、ＦＡＴファイルシステムを使用する場合よりも高度な管理が可能になる。
【０２３１】
（５）第２のファイルシステムとして、サブブロック単位でなく論理セクタ単位に管理できる。
【図面の簡単な説明】
【図１】本発明のブリッジファイルシステム及び記録媒体の一実施の形態の概略説明図である。
【図２】 本発明の記録媒体の記録領域の先頭付近の利用状況の一実施の形態を示す図である。
【図３】 本発明のブリッジファイルシステムにおけるブロック毎の管理情報を示すための各種フラグの定義例を示す図である。
【図４】 第１のビットマップテーブルの一例を示す図である。
【図５】 第２のビットマップテーブルの一例を示す図である。
【図６】 本発明におけるファイル管理情報の一例を示す図である。
【図７】 本発明になる記録媒体の一実施の形態の記録情報の説明図である。
【図８】 図７に対応する第１のビットマップテーブルの例を示す図である。
【図９】サブブロックに分割した基本ブロックの第２のビットマップテーブル（ビットマップ本体のみ）を示す図である。
【図１０】図７の基本ブロックの第２のビットマップテーブルを示す図である。
【図１１】第１のビットマップのデータの求め方を示した図である。
【図１２】図７の２つの基本ブロックのビットマップデータを取得する手順を示した図である。
【図１３】 ファイルインフォメーションの一例を示す図である。
【図１４】 ディレクトリ内でファイルを管理する一例の説明図である。
【図１５】 第１のビットマップテーブルの記録媒体上の配置例である。
【図１６】 ビットマップテーブルサイズが論理セクタサイズよりも大きい第２のビットマップテーブルの記録媒体上の配置例を示す図である。
【図１７】 ビットマップテーブルサイズが論理セクタサイズよりも小さい第２のビットマップテーブルの記録媒体上の配置例を示す図である。
【図１８】 スタッフィングのためのダミーデータの配置方法を説明するための図である。
【図１９】 管理情報内に管理情報部分のサイズを格納できるようにした図である。
【図２０】ＦＡＴ１２またはＦＡＴ１６ファイルシステムとのブリッジの例を示す図である。
【図２１】ファイルシステム＃１のファイル配置情報の例である。
【図２２】ＦＡＴファイルシステム上のファイル管理情報の１つであるディレクトリエントリから関係する情報だけを抜き出して示した図である。
【図２３】 ＦＡＴファイルシステムのもう一つのファイル管理情報であるＦＡＴの例を示す図である。
【図２４】図２２と図２３から抽出した各ファイルのクラスタチェインを示す図である。
【図２５】ＦＡＴ３２ファイルシステムにおいて、ＲＯＯＴディレクトリがデータ領域の途中に置かれることを示す図である。
【図２６】ＩＳＯ９６６０の概要を示した図である。
【図２７】 ＵＤＦの概要を示した図である。
【図２８】ＩＳＯ９６６０とＵＤＦとのブリッジを示した図である。
【図２９】 ＦＡＴファイルシステムの構造を説明するための図である。
【図３０】 代表的なファイルシステムの容量とクラスタサイズの関係を示す図である。
【図３１】 特開平８−１０１７８３号公報記載の従来のファイルシステムの一例の構成図である。
【図３２】 外部フラグメンテーションと内部フラグメンテーションを示す図である。
【符号の説明】
１００ 記録媒体
１８１ ビットマップテーブルの管理情報
１８２ ビットマップテーブル本体
１８３、１９２ ダミーデータ
１９１ 管理情報本体
１９３ 管理情報全体のサイズ
【発明の属する技術分野】
本発明はブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体に係り、特に記録媒体にデータを記録再生する際の管理構造や管理方式を規定するブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体に関する。
【０００２】
【従来の技術】
ファイルシステムは、記録媒体にデータを格納し、取り出すために、記録媒体上の記録領域をどのように使用するかを規定する。これまで様々なＯＳ（オペレーションシステム）や組み込み機器のため多くのファイルシステムが開発されてきたが、その中でＦＡＴファイルシステムは、歴史的に殆どすべてのＯＳでサポートされてきた基本的なファイルシステムの一つで、汎用的でデータ交換性に優れることから、リムーバブルメディアのデファクトスタンダードとなっている。
【０００３】
詳しくは後述するが、その特徴はクラスタと呼ばれる固定ブロック単位のデータ配置方式、ファイル・アロケーション・テーブル（File Allocation Table：ＦＡＴ）でのクラスタチェインを用いた配置管理、階層ディレクトリによるファイル管理などである。その他、クラスタ単位のファイル管理を行うファイルシステムとしてはウィンドウズＮＴのファイルシステムであるＮＴＦＳ（NT File System）などがある。なお，本明細書において、「ウィンドウズ」は登録商標である．
【０００４】
クラスタ単位の管理方法を用いるファイルシステムは、詳しくは後述するが、ファイルサイズとクラスタサイズのミスマッチや、クラスタの分断などによるフラグメンテーションの問題があるため、特開平８−１０１７８３号公報では、２種類のクラスタを用意してファイルサイズによって記録する領域を選ぶ新しいファイルシステムを提案している。
【０００５】
また、光ディスク系の媒体においては、ＩＳＯ９６６０やＩＳＯ９６６０をベースとしたファイルシステム、ＵＤＦ等のファイルシステムが利用されている。ＤＶＤ−Ｖｉｄｅｏにおいては、新しいファイルシステムである ＵＤＦを採用するにあたり、従来のファイルシステムであるＩＳＯ９６６０からも利用できるように、ＵＤＦとＩＳＯ９６６０の２つのファイルシステムが共存するブリッジファイルシステムが採用され、利用者は特定のファイルにアクセスするのにどちらのファイルシステムでも利用できるようになっている。
【０００６】
このように、ブリッジファイルシステムの採用は、情報交換用の記録媒体に新フォーマットを導入する際に利用者に受け入れやすい形式であるといえる。
【０００７】
【発明が解決しようとする課題】
近年のディジタル画像処理技術の進歩により、ＡＶストリームのリアルタイム記録再生を行う機器が発売されるようになった。ＡＶストリームデータを記録媒体に記録再生するために、記録媒体上での配置や取り扱いを規定するためにファイルシステムが使用されるが、従来のファイルシステムは幾つかの課題を抱えており、ＡＶストリームのリアルタイム記録再生にとっては必ずしも最適ではない。
【０００８】
（１）ＦＡＴファイルシステムとその一般的な課題
初めにＦＡＴファイルシステムについて簡単に説明した後、その問題点を述べる。記録媒体は一般にセクタと呼ばれる固定サイズの連続領域を最小単位としてデータの記録再生を行っている。データは記録再生に伴うエラーを回避するため、誤り訂正用の情報やそのほかの管理情報等を付加して記録再生されるが、有効データ部分については一般にそのサイズは２のべき乗で規定される。
【０００９】
例えば、一般に用いられるサイズは、ハードディスクの場合５１２バイト（＝２９バイト）で、ＣＤＲＯＭやＤＶＤＲＯＭ等の光ディスクの場合は一般に２０４８バイト（＝２１１バイト）である（小容量のＭＯは５１２バイト）。ただし、ハードディスクの場合、５１２バイト以外の２のべき乗の論理セクタサイズをとることも可能だが、実質的に５１２バイト以外で用いられることは殆どない。
【００１０】
大容量化した記録媒体においては、この論理セクタ数は膨大になり、効率良く管理するには不利なので、いくつかのファイルシステムでは複数の論理セクタを一定個数まとめて記録媒体を管理する手法をとっている。ウィンドウズＮＴのファイルシステムであるＮＴＦＳ（NT File System）や、ＭＳ−ＤＯＳやウィンドウズ3.1/95で使用されるＦＡＴファイルシステムはこのようなファイルシステムの例である。
【００１１】
図２９はＦＡＴファイルシステムの構造を説明するための図で、全体は図２９（ａ）に示すように、システム領域１、２つのＦＡＴ２、３、ルートディレクトリ領域４、データ領域５から構成される。
【００１２】
データ領域５はクラスタと呼ばれる連続する複数セクタ単位に分割して使用され、クラスタと１対１に対応するエントリを持つ管理テーブルであるＦＡＴを使ってファイルの配置情報を管理する。各クラスタには、順番に番号（クラスタ番号）が振られる。
【００１３】
図２９（ａ）に２及び３で示すように、ＦＡＴは２つあって、１つは予備である。また、システム領域１にはＯＳのブートコードやファイルシステム全体の管理情報などが格納されている。記録データはディレクトリ上でファイルとして記録され、ルートディレクトリを頂点とする任意の木構造からなる階層構造を構成する。
【００１４】
ルートディレクトリ４以下のディレクトリはサブディレクトリと呼ばれ、１つの特殊なファイルとして管理される。ディレクトリの構造はルートディレクトリもサブディレクトリも同じで、ディレクトリエントリのテーブルになっている。
【００１５】
１つのディレクトリエントリには、記録データの内容を表すファイル名等の情報とともに、データの先頭が格納されているクラスタのクラスタ番号をファイルのエントリ情報として記録する。
【００１６】
ＦＡＴはクラスタ番号のテーブルになっており、図２９（ｂ）に示すように、ファイルエントリで示されるクラスタ番号に対応するエントリには、ファイルデータの連結状態を示すために次のクラスタ番号が記録され、複数のクラスタに分散されたデータのつながり（クラスタチェイン）を管理することができる。ファイルの最後のクラスタには最終クラスタであることを示す識別子（ＦＡＴ１６の場合、ＦＦＦＦ）が記録される。このように、ＦＡＴファイルシステムにおいては、ファイルはディレクトリとＦＡＴの２つを用いて管理される。
【００１７】
なお、クラスタ内に欠陥セクタがあると、そのクラスタは使用不可能な領域であることを示す識別子がＦＡＴに記録されるので、このクラスタは使用しない。従って、たとえ１セクタでも不良の領域があった場合は、そのセクタが属するクラスタ全体が使用不可能となるため、クラスタサイズが大きいほど効率的な使用の妨げになる。
【００１８】
ＦＡＴ上のクラスタエントリの内容は、クラスタ番号を意味するので、そのエントリに与えるビット数によって、ファイルシステム全体で扱えるクラスタの数が決まる。ＦＡＴファイルシステムには、そのビット数の違いで幾つかのバージョンがあり、ＦＡＴ１２、ＦＡＴ１６、ＦＡＴ３２ファイルシステムと呼ばれることがある。
【００１９】
ＦＡＴ１２、ＦＡＴ１６、ＦＡＴ３２などの数字の部分はクラスタ番号のビット数を示し、それぞれ１２ビット、１６ビット、３２ビットを意味している。従って、各ファイルシステムが扱えるクラスタの総数は、それぞれおよそ２の１２乗、２の１６乗、２の３２乗個程度になる。実際には予約番号等があるためにこれらの数字より若干小さい値となる。図２９（ｂ）に示すＦＡＴは、ＦＡＴ１６の例である。
【００２０】
ＦＡＴファイルシステムの場合、クラスタサイズは記録媒体の容量によってある一定値に決定され、記録媒体の容量が大きくなるほど大きくなる。図３０は代表的なファイルシステムの容量とクラスタサイズの関係を示す。
【００２１】
しかし、上記のＦＡＴファイルシステムでは、クラスタと呼ぶ一定サイズの記録単位でファイルの記録再生を行うため、記録単位のサイズがファイルサイズにとって必ずしも最適とはならない。
【００２２】
これを解決するための手段として、従来は特開平８−１０１７８３号公報では、通常のクラスタサイズのほかに、クラスタをさらにサブクラスタに分割して、２種類のクラスタサイズを用意しているファイルシステムが開示されている。これによって、大きいファイルは通常のクラスタの領域に、小さいファイルはサブクラスタの領域に、ファイルサイズに応じて選択して記録する。
【００２３】
図３１は上記の特開平８−１０１７８３号公報記載の従来のファイルシステムの一例の構成図を示す。このファイルシステムは、映像情報やオーディオ情報処理用のコンピュータ７に、キャッシュメモリ８を介して直接アクセス装置９としての磁気ディスク装置を接続して構成されており、磁気ディスク装置内の制御部は磁気ディスクに対するヘッダ部の制御と共に、コンピュータ７からの命令に従って、所定のファイルの読み書き制御をする。このとき、制御部は、磁気ディスクを、先頭番地からファイル・アロケーション・テーブルを格納する５１２ｋバイトのシステム領域Ｒ１と、個々のデータファイルを格納するデータ領域Ｒ２に分割して管理する。
【００２４】
データ領域Ｒ２は、５１２ｋバイトの複数のクラスタＣ１、Ｃ２、・・・、Ｃｘに分割され、更にクラスタは１２８ｋバイトの複数のサブクラスタＳＣ１、ＳＣ２、・・・、ＳＣ５に細分割管理してあり、システム領域Ｒ１に設定されたファイル・アロケーション・テーブルにデータ領域Ｒ２に割り付けるべきファイル情報を格納して管理するようにされている。
【００２５】
すなわち、この従来のファイルシステムでは、ファイルサイズの違いによる使用効率やアクセス効率の改善を図るために、記録媒体を、ファイル・アロケーション・テーブルを格納するシステム領域Ｒ１と、個々のデータファイルを格納するデータ領域Ｒ２に分割し、データ領域Ｒ２を大容量の複数のクラスタＣ１、Ｃ２、・・・、Ｃｘに分割するとともに、このクラスタを複数のサブクラスタＳＣ１、ＳＣ２、・・・、ＳＣ５に細分割できるようにしている。さらに、サブクラスタの先頭領域には、システム領域に格納されたファイル・アロケーション・テーブルに関連付ける第２のファイル・アロケーション・テーブルを配置し、サブクラスタ内のファイルの配置を管理している。
【００２６】
従って、ＡＶデータ等の大容量ファイルデータは、システム領域のファイル・アロケーション・テーブルの管理に従って、大容量のクラスタに割り付け、テキストデータ等の小容量のファイルデータはサブクラスタに割り付けることにより、記録媒体の使用効率を向上する。また、上記のサブクラスタＳＣ１、ＳＣ２、・・・、ＳＣ５への分割は、取り扱うべき複数のテキストファイル等の容量に基づいて、システムの初期設定時に予め固定することにより、記録媒体の使用効率を向上する。
【００２７】
なお、特開平８−１０１７８３号公報に記載の用語「ファイル・アロケーション・テーブル」は、ＦＡＴファイルシステムにおけるＦＡＴの名称と同じであるが、内容は異なるので注意を要する。特開平８−１０１７８３号公報における「ファイル・アロケーション・テーブル」は、ファイル名とそのクラスタチェインのリスト構造であり、ＦＡＴファイルシステムのようなクラスタエントリのテーブルは存在しない。
【００２８】
【発明が解決しようとする課題】
しかし、前記ＦＡＴファイルシステムにおけるクラスタによる記録領域の管理方法には一般に次のような弊害がある。
（ａ）外部フラグメンテーション
ＦＡＴファイルシステムのように、クラスタ単位でデータ配置を管理する媒体の運用を続けていると、ファイルの削除、作成といったファイル操作の繰り返しによって、図３２にＸで示すように、媒体上のファイル配置がクラスタ単位でばらばらになっていく。これを外部フラグメンテーションと呼び、外部フラグメンテーションの発生個所では、機械構造を持つ記録デバイスにおいてはヘッドシークが発生するためアクセス速度の低下を招くという欠点がある。
【００２９】
機械構造を持たないフラッシュメモリなどの電気的デバイスにおいては、中央処理装置（ＣＰＵ）の処理能力やバスの転送速度などが十分な場合は、軽微な問題ではあるものの、データ転送手続きを分割する手間等の増加によるパフォーンスの低下という影響がある。
【００３０】
この問題の解消のために、一般にはデフラグというツールを用い、クラスタ単位のデータの並び替えを行ってデータの連続化を行う方法がある。しかしデフラグの実行は膨大な時間とリソースの消費を招くため、アプリケーション実行時の重大な妨げになる。
【００３１】
（ｂ）内部フラグメンテーション
クラスタ単位でデータを扱うため、クラスタサイズ未満のファイルを記録すると、図３２にＹで示すように最終クラスタ内に未使用領域が発生する。これを内部フラグメンテーションまたはクラスタギャップと呼び、記録媒体の使用効率の低下を招く。ここでは、（ａ）の外部フラグメンテーションと対比する意味で内部フラグメンテーションという用語を用いる。一般に、記録容量が大きいほどクラスタサイズが大きくなるため、内部フラグメンテーションが増大し、記録媒体の使用効率が下がるという欠点がある。
【００３２】
（ｃ）欠陥領域
従来のＦＡＴファイルシステムでは、たとえ１セクタでも不良の領域があった場合は、そのセクタが属するクラスタ全体が使用不可能となるため、クラスタサイズが大きいほど効率的な使用の妨げになる。
【００３３】
（ｄ）交替領域
ＤＶＤ−ＲＡＭのように、デバイスが欠陥領域を自動的に交替領域に割り当てるものがあるが、欠陥領域の管理単位がクラスタサイズと一致しないため、クラスタ内の論理アドレスが連続していても物理アドレスは不連続になり、実質的に外部フラグメンテーションが発生していることと同じ状況になってしまう場合がある。
【００３４】
（ｅ）テーブルサイズ
ＦＡＴのテーブルサイズの最大値は、ほぼクラスタに与えるエントリのビット数とクラスタの数の積になるため、記録媒体の容量が大きい場合は膨大なサイズとなる。例えば、２ＧＢのＦＡＴ１６ファイルシステムの場合、ＦＡＴのサイズは約１２０ｋバイトである。新しくファイルを記録する場合は、事前にＦＡＴを調査して未使用領域を探す必要がある。この場合、１２０ｋバイトものテーブルをサーチして空き領域を探す必要があるため効率が悪い。
【００３５】
また、大きいサイズのテーブルをメモリ上に保持することは、システムリソースを圧迫し、特に組み込み用機器等、リソースが貧弱な機器にとっては甚だしく不利である。かといってメモリ上にテーブルを持たないと、上記データが必要になる度に、記録媒体にアクセスする必要があるため効率が低下するという問題がある。
【００３６】
また、前記の特開平８−１０１７８３号公報には、ファイルサイズの違いによる使用効率やアクセス効率の改善を図るという、特定の用途に最適化するための新しいファイルシステムが開示されている。しかし、このように特定の用途に最適化するために新しいファイルシステムを導入すると、通常のコンピュータシステムでは、この媒体にアクセスできないという問題がある。
【００３７】
この場合、新しいファイルシステム用のデバイスドライバ等をシステムに組み込む必要があるため、ユーザーにシステムの変更や手間を要求することになり、情報交換性という点ではあまり好ましくない。また、各種コンピュータシステムに対応するために多くの種類のドライバを配布し、それを適切に誤りなく組み込むことは難しい。
【００３８】
（２）その他のファイルシステムについて（ＮＴＦＳ）
ＮＴＦＳは、ＦＡＴファイルシステムと同様にクラスタ単位のファイル配置を行うが、ＦＡＴよりも比較的フラグメンテーションが発生しにくく、信頼性を向上させる仕組みや、より細かい属性設定が可能などのいくつかの特徴を持つ。従って、ＦＡＴファイルシステムより、柔軟で高度な管理が可能である。
【００３９】
ＮＴＦＳの構造上の特徴は、パーティション内のすべてのファイルやディレクトリ毎に固定長の管理レコードを作成し、これを集中的に管理している。この管理レコード群はマスター・ファイル・テーブル（ＭＦＴ：Master File Table）と呼ばれる１つのファイルである。
【００４０】
各管理レコードは固定長であり、このサイズに納まるような小さいファイルは管理レコード内で完結するように保存される。一方、管理レコードのサイズを越える大きいファイルは、ＭＦＴ以外の領域に一連の新しいクラスタが割り当てられ、そこへのインデックスが管理レコードに保存される。従って、このような大きいファイルではＦＡＴファイルシステムと同様にクラスタ単位のフラグメンテーションが発生する可能性がある。従って、この点については特にＦＡＴファイルシステムより優れているわけではない。
【００４１】
また、ＭＦＴ自体も一つのファイルであるため、ＭＦＴに最初に割り当てられるサイズを越えると、その度に３２レコード分の拡張が行われ、フラグメンテーションが発生する。ＮＴＦＳでは、ＭＦＴのフラグメンテーションは顕著な効率低下を招くので望ましくない。
【００４２】
（３）その他のファイルシステムについて（ＩＳＯ９６６０とＵＤＦ）
光ディスクではＣＤ−ＲＯＭの標準論理フォーマットとして用いられているＩＳＯ９６６０規格に対し、再生専用・追記・書き換え型の物理特性を持つ各ディスクに共通に適用可能で、汎用性や拡張性を重視したＵＤＦ（Universal Disk Format）ファイルシステムが開発されており、ＤＶＤやＣＤ−ＲＷ等で採用されている。
【００４３】
ＩＳＯ９６６０とＵＤＦのどちらも論理セクタの連続する塊としてファイル配置を表現するファイルシステムであるが、管理構造は異なっている。ＵＤＦのボリューム空間は、ＣＤ−ＲＯＭのボリューム構造を含むように構成できるようになっており、ＤＶＤ−ＲＯＭディスクなどの再生専用ディスクでこのようなブリッジ構造を実現している。
【００４４】
このようなブリッジ構造の採用により、既存のコンピュータシステムは新しいファイルシステムであるＵＤＦファイルシステムを使用しなくても、標準的に搭載されているＩＳＯ９６６０ファイルシステムを使用して、ディスク上に記録されたファイルにアクセスすることが可能になる。
【００４５】
（４）特定用途に対する問題点
近年、ハードディスクドライブ（ＨＤＤ）を用いて、ＡＶストリームのリアルタイム記録再生を行う機器が発売されるようになった。このＡＶストリームは、高いビットレートでリアルタイムに伝送する必要があるため、外部フラグメンテーションによるアクセス効率の低下は、リアルタイムの記録再生に障害となる場合がある。
【００４６】
そこで、クラスタ内の領域は連続領域に記録されることから、外部フラグメンテーションの影響を少なくするために、クラスタサイズを大きくする方法が考えられる。これによって、データに連続的にアクセスできるようになるため、アクセス速度の保証が可能になり、ＡＶストリーム等のリアルタイム記録再生に有利である。たとえ、外部フラグメンテーションが発生しても、もともとクラスタサイズが大きいため、ヘッドシークによるアクセス速度の低下を無視できる程度に下げることができる。
【００４７】
このようにクラスタサイズを大きくすると、外部フラグメンテーションの影響を最小化することが可能だが、その反面、サイズの小さなファイルに対して内部フラグメンテーションが増大し、ハードディスクの使用効率が低下するという問題がある。
【００４８】
すなわち、ＡＶストリームは一般にファイルサイズが大きくなるため、外部フラグメンテーションに関する問題は少ないが、これを管理するためのファイルや一般のファイルは、ＡＶストリームと比較するとサイズが小さく、しかも数多く作成されるため、これらのファイルに対する内部フラグメンテーションがハードディスクの効率的な使用を妨げていた。
【００４９】
（５）リムーバブルメディアの可換性の問題
前記（４）のような問題を解決するために新しいファイルシステムを導入する場合、組み込み型の記録媒体であれば、閉じたシステムであるため全く独自のファイルシステムを導入しても問題ない。
【００５０】
しかし、リムーバブルのＨＤＤや不揮発性メモリカード等を搭載したムービーで利用する場合、これらの記録媒体をパソコンなどの既存のコンピュータシステムで利用できれば優れた情報交換性を発揮できる。この時、記録媒体に対して独自のファイルシステムでファイルを記録していた場合、既存のコンピュータシステムは、そのままでは認識できない。このような場合はユーザーに対しそのファイルシステムのためのデバイスドライバを組み込むことが要求され、情報交換性を著しく阻害することになる。
【００５１】
本発明は、以上の点に鑑みなされたもので、２つのファイルシステムを共存させ、どちらのファイルシステムからでも、記録された情報をアクセスし得るブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体を提供することを目的とする。
【００５２】
また、本発明の他の目的は、サイズの大きなＡＶストリームデータから、サイズの小さなＡＶストリームの管理情報などのファイルまでを最適に記録し得るブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体を提供することにある。
【００５３】
また、本発明の他の目的は、殆どすべてのコンピュータシステムに適用し得るブリッジファイルシステム及び記録媒体を提供することを目的とする。
【００５４】
更に、本発明の他の目的は、ＦＡＴシステムを使用する場合よりも高度な管理が可能なブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体を提供することにある。
【００５５】
また、本発明の更に他の目的は、論理セクタ単位に管理し得るブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体を提供することにある。
【００５６】
【課題を解決するための手段】
上記の目的を達成するために。第１の発明は、記録媒体上の連続する記録領域を複数の論理セクタから構成される一定サイズの基本ブロック毎に分割し、該基本ブロック単位でデータを配置して管理する第１の管理方法と、任意の前記基本ブロックを各々同一サイズの複数の論理セクタから構成される複数のサブブロックに分割し、そのサブブロック単位でデータを配置して管理する第２の管理方法を持ち、前記第１及び第２の管理方法のうち選択した管理方法でデータを記録再生する第１のファイルシステムと、前記記録領域を前記サブブロックと同一サイズのブロック単位でデータを配置して管理する第２のファイルシステムとが共存するブリッジファイルシステムであって、前記記録領域のデータファイルに対し、前記第１及び第２のファイルシステムの両方からアクセス可能な管理構造を有し、前記第１のファイルシステムは、前記記録領域内の前記基本ブロック毎の状態を表すフラグの集合とその管理情報が記録された第１のビットマップテーブルを前記記録領域上に配置し、前記サブブロックに分割された前記基本ブロックは、その基本ブロック内のサブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブルを該当する基本ブロック毎に対応付けて前記記録領域上に配置し、前記第２のファイルシステムの管理情報のうち、前記第１のファイルシステムが参照可能な前記記録領域に配置される管理情報がある場合は、前記第１のファイルシステムの前記サブブロックのエリアに配置し、前記第２のファイルシステムは、前記第１及び第２のビットマップテーブルをファイルとして参照可能で、前記第２のファイルシステムにおけるブロック毎の使用状態とファイルの配置状態を管理する第３のテーブルを持つブリッジファイルシステムである。
【００５７】
また、第２の発明は、第１のブリッジファイルシステムにおいて、前記第２のファイルシステムはＦＡＴファイルシステムであり、前記第３のテーブルはファイルアロケーションテーブル（ＦＡＴ）である。
【００５８】
また、第３の発明は、第１のブリッジファイルシステムにおいて、前記第２のファイルシステムはＮＴＦＳファイルシステムであり、前記第３のテーブルはマスターファイルテーブル（ＭＦＴ）である。
【００５９】
また、第４の発明は、第１のブリッジファイルシステムにおいて、前記第１のファイルシステムは、前記記録領域内の前記基本ブロック毎の状態を表すフラグの集合とその管理情報が記録された第１のビットマップテーブルを前記記録領域上に配置し、前記サブブロックに分割された前記基本ブロックは、その基本ブロック内の前記サブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブルを該当する基本ブロック毎に対応付けて前記記録領域上に配置し、前記第２のファイルシステムは、前記第１及び第２のビットマップテーブルをファイルとして参照可能で、前記第２のファイルシステムの管理情報のうち、前記第１のファイルシステムのデータエリアに配置される管理情報がある場合は、前記第１のファイルシステムの前記サブブロックのエリアに配置し、前記記録領域のデータファイルに対し、前記第１及び第２のファイルシステムの両方からアクセス可能な管理構造を有する。
【００６０】
また、第４の発明は、第４のブリッジファイルシステムにおいて、前記第２のファイルシステムは、ＩＳＯ９６６０またはＵＤＦである。
【００６１】
また、第６の発明は、記録媒体上の連続する記録領域を複数の論理セクタから構成される一定サイズの基本ブロック毎に分割し、該基本ブロック単位でデータを配置して管理する第１の管理方法と、任意の前記基本ブロックを各々同一サイズの複数の論理セクタから構成される複数のサブブロックに分割し、そのサブブロック単位でデータを配置して管理する第２の管理方法を持ち、前記第１及び第２の管理方法のうち選択した管理方法でデータを記録再生する第１のファイルシステムと、前記記録領域を前記サブブロックと同一サイズのブロック単位でデータを配置して管理する第２のファイルシステムとが共存するブリッジファイルシステムをコンピュータに搭載したコンピュータシステムであって、前記記録領域のデータファイルに対し、前記第１及び第２のファイルシステムの両方からアクセス可能な管理構造を有し、前記第１のファイルシステムは、前記記録領域内の前記基本ブロック毎の状態を表すフラグの集合とその管理情報が記録された第１のビットマップテーブルを前記記録領域上に配置し、前記サブブロックに分割された前記基本ブロックは、その基本ブロック内のサブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブルを該当する基本ブロック毎に対応付けて前記記録領域上に配置し、前記第２のファイルシステムの管理情報のうち、前記第１のファイルシステムが参照可能な前記記録領域に配置される管理情報がある場合は、前記第１のファイルシステムの前記サブブロックのエリアに配置し、前記第２のファイルシステムは、前記第１及び第２のビットマップテーブルをファイルとして参照可能で、前記第２のファイルシステムにおけるブロック毎の使用状態とファイルの配置状態を管理する第３のテーブルを持つブリッジファイルシステムをコンピュータに搭載したコンピュータシステムである。
【００６２】
また、第７の発明は、記録媒体上の連続する記録領域を複数の論理セクタから構成される一定サイズの基本ブロック毎に分割し、該基本ブロック単位でデータを配置して管理する第１の管理方法と、意の前記基本ブロックを各々同一サイズの複数の論理セクタから構成される複数のサブブロックに分割し、そのサブブロック単位でデータを配置して管理する第２の管理方法を持ち、前記第１及び第２の管理方法のうち選択した管理方法でデータを記録再生する第１のファイルシステムと、前記記録領域を前記サブブロックと同一サイズのブロック単位でデータを配置して管理する第２のファイルシステムとが共存するブリッジファイルシステムを用いたデータ管理方法であって、前記第１及び第２のファイルシステムは、前記第１のファイルシステムに基づき前記記録領域に記録された第１のデータファイルと前記第２のファイルシステムに基づき前記記録領域に記録された第２のデータファイルのいずれに対しても、それぞれアクセス可能であり、前記第１のデータファイルを、前記基本ブロック毎の状態を表すフラグの集合とその管理情報とからなる第１のビットマップテーブル、又は前記サブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブルが、前記基本ブロック単位又は前記サブブロック単位で記録されたテーブル領域と、データが前記基本ブロック単位又は前記サブブロック単位で記録されたデータ領域とが分離された構造とし、
前記第１及び第２のビットマップテーブルの前記フラグの集合には、そのビットマップテーブルにより管理する前記第１のデータファイル中のデータ領域に、専用のアクセス手段によってのみアクセス可能な一時削除ファイルが記録されていることを示す第１のフラグと、予め記録する領域を確保するために特別に設けられた予約領域ファイルが確保されていることを示す第２のフラグとを含み、前記第１及び第２のビットマップテーブルにより、前記データ領域に記録するデータを管理することを特徴するブリッジファイルシステムを用いたデータ管理方法である。
【００６５】
【発明の実施の形態】
次に、本発明の一実施の形態について図面と共に説明する。図１は本発明になるブリッジファイルシステム及び記録媒体の一実施の形態の概略説明図を示す。同図において、記録媒体１００上の連続する記録領域には、第１のファイルシステムの第１又は第２のビットマップテーブル１０１と、第２のファイルシステムの第３のテーブル１０２とが記録されている。また、第１のファイルシステムによるファイル１０３、１０４が記録媒体１００上に記録されている。
【００６６】
ここで、上記の第１のファイルシステムは、記録媒体１００上の連続する記録領域を複数の論理セクタから構成される一定サイズの基本ブロック毎に分割し、基本ブロック単位でデータを配置して管理する第１の管理方法と、任意の前記基本ブロックを各々同一サイズの複数の論理セクタから構成される複数のサブブロックに分割し、そのサブブロック単位でデータを配置して管理する第２の管理方法を持ち、前記第１及び第２の管理方法のうち選択した管理方法でデータを記録再生する。
【００６７】
この第１のファイルシステムは、上記の記録領域内の基本ブロック毎の状態を表すフラグの集合とその管理情報が記録された第１のビットマップテーブル１０１を記録媒体１００上に配置し、サブブロックに分割された基本ブロックは、その基本ブロック内のサブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブル１０１を該当する基本ブロック毎に対応付けて記録媒体１００上に配置し、第２のファイルシステムの管理情報のうち、第１のファイルシステムのデータエリアに配置される管理情報がある場合は、第１のファイルシステムの前記サブブロックのエリアに配置する。
【００６８】
また、上記の第２のファイルシステムは、上記の記録領域をサブブロックと同一サイズのブロック単位でデータを配置して管理する既存のファイルシステムである。この第２のファイルシステムは、第１及び第２のビットマップテーブルをファイルとして参照可能で、第２のファイルシステムにおけるブロック毎の使用状態とファイルの配置状態を管理する第３のテーブル１０２が記録されている。
【００６９】
これにより、第１のファイルシステムに対応したコンピュータシステム１０５は、第１又は第２のビットマップテーブル１０１に基づいて、ファイル１０３や１０４の再生ができる。また、既存の第２のファイルシステムが搭載されているコンピュータシステム１０６においても、第３のテーブル１０２に基づいて記録されたファイル１０３及び１０４にアクセスできる。このように、本発明では第１及び第２のファイルシステムのどちらからもアクセスできるようにしたので、第２のファイルシステムとして、コンピュータシステムに標準的に搭載されているファイルシステムを採用すれば情報交換が容易になる。
【００７０】
なお、第１のファイルシステムに対応したコンピュータシステム１０５が、第３のテーブル１０２に基づいて、ファイル１０３、１０４をアクセスすることは可能であるが、第１又は第２のビットマップテーブル１０１を参照した方が最大効率でファイル１０３、１０４をアクセスできるので、第３のテーブル１０２を用いてアクセスすることは特に必要ではない。
【００７１】
次に、本発明のブリッジファイルシステムの一実施の形態のデータ領域の使用方法について説明する。ｎを２以上の自然数、ｍを任意の自然数とすると、複数の一定サイズの論理セクタで構成される記録媒体のデータ領域をｍｎセクタ毎の基本ブロックに分割し、識別番号として先頭から順番にブロック番号を振る（ｍｎはｍ×ｎの意味）。
【００７２】
各基本ブロックは、連続するｍセクタからなる、ｎ個のサブブロックに分割することができる。データを記録する場合は、基本ブロック単位またはサブブロック単位に記録する。
【００７３】
図２は本発明の記録媒体の記録領域の先頭付近の利用状況の一実施の形態を示す。同図において、各ブロックのサイズはｍｎセクタ分のサイズであり、ブロック番号１，２，４が基本ブロック単位で使用され、ブロック番号０、３がｎ個のサブブロックに分割して使用されている。サブブロックへの分割は必要に応じて行うものとし、フォーマット時は分割されていない基本ブロックのみでもよい。
【００７４】
記録媒体へのデータ配置をこのようにしておくことにより、一般に基本ブロックよりも大きいサイズのファイルは分割しないブロックにそのまま記録し、基本ブロックよりある程度小さいサイズのファイルは、サブブロックに記録することによって、２つのメリットが得られる。
【００７５】
１つは、大きいファイルは基本ブロック単位でしか外部フラグメンテーションが発生しないので、ＨＤＤ等に適用した場合、ヘッドシークの発生を最小限にでき、アクセス効率が向上する点である。もう１つは、小さいファイルはサブブロックに配置するため、内部フラグメンテーションによって発生する可能性のある無駄な領域をサブブロックのサイズ以下に抑えることができる点である。
【００７６】
サブブロックへ分割する際のサイズの基準は、任意に設定できるが、基本ブロックに占めるデータの割合が大きい場合に、基本ブロックとして使用するのが一般的にはよい。例えば、基本ブロックサイズの８０％を越える場合には基本ブロックとして扱い、そうでない場合はサブブロックに分割する。この設定によって、基本ブロックで発生する内部フラグメンテーションによる使用効率の低下は、最終基本ブロックサイズの２０％以下に抑えることができる。
【００７７】
また、基本ブロックより大きいファイルは、複数の基本ブロックに書き込まれることになるが、最終ブロックについては基本ブロックより小さいファイルと同等の状況になるので、このようなファイルに対しては、最終ブロック以外は基本ブロック単位で扱い、最終ブロックについては、前記基準を適用して、場合によってはサブブロックに分割するようにしてもよい。
【００７８】
なお、この基準は絶対的なものではなく、０％から１００％まで、システムやアプリケーションのポリシーによって自由に設定することができる。例えば、将来追加書き込みが予想されるファイルは、無条件に基本ブロックとして扱ったほうがよい。その理由は、サブブロックに分割した後で残りの領域に別なファイルが書き込まれた場合、追加書きこみデータを連続領域に書き込めないからである。逆に、アクセス性よりも使用効率の方が重要であるなら、サブブロックへの分割の優先度をあげ、必ず分割するようにしてもよい。
【００７９】
次に、本発明において、前記２種類のデータ配置を効率良く管理する方法について説明する。
【００８０】
本発明の特徴の１つは、データ領域の使用状況等を示す管理情報をデータの配置情報と分離して用意したことである。この管理情報は、データ領域の２種類の利用方法に対応した２種類のビットマップテーブルによって実現している。
各基本ブロックおよびサブブロックは、それぞれ自分のブロックに対応する数ビットのフラグを持ち、このフラグの組み合わせによって、ブロックの使用状態等を判断することができる。
【００８１】
図３は本発明のブリッジファイルシステムにおけるブロック毎の管理情報を示すための各種フラグの定義例を示す。図３では、一つのブロックについて、ビット（ｂｉｔ）０〜３の４つのフラグを割り当てており、第１と第２のビットマップテーブルでほぼ共通に使用することができる。
【００８２】
同図において、ビット０のスケール（ｓｃａｌｅ）フラグは、基本ブロックを基本ブロック全体として使用しているか、サブブロックに分割して使用しているかを示すフラグで、０のときサブブロックに分割して使用していることを示す。このフラグは、第１のビットマップテーブルで使用するときのみ有効で、第２のビットマップテーブルでは、使用しない。あるいは、ここでは解説しない別な用途に用いてもよい。
【００８３】
ビット１のユーザブル（ｕｓａｂｌｅ）フラグは、そのブロックに利用可能な空き領域があるかどうかを示すフラグで、ｓｃａｌｅフラグの内容によって若干意味が異なり、ｓｃａｌｅフラグが１の時は、その基本ブロックが完全に未使用であるかどうかを示し、ｓｃａｌｅフラグが０の時は、完全に未使用なサブブロックが存在するかどうかを示す。すなわち、どちらの場合も利用可能なブロックがある場合に１にする。
【００８４】
従って、ｓｃａｌｅフラグとｕｓａｂｌｅフラグの２つのビットを検索することによって、基本ブロック又はサブブロック単位で未使用なブロックがあるかどうか簡単に判断することができる。
【００８５】
ビット２のプリアロケーテッド（ｐｒｅａｌｌｏｃａｔｅｄ）フラグは、そのブロックを記録に先だって予約しておくためのフラグであり、１のときにそのブロックが予約領域であることを示す。更に、ビット３のディフェクト（ｄｅｆｅｃｔ）フラグは、１のときはそのブロックに欠陥領域があって使用できないことを示し、０のときはそのブロックに欠陥領域がなく使用可能であることを示す。
【００８６】
なお、図３は一例であって、予約領域をサポートしない場合は、プリアロケーテッドフラグはなくてもよい。また、欠陥領域をサポートしない場合は、ｄｅｆｅｃｔフラグはなくてもよい。また、図３に示す以外のその他の管理情報を示すフラグがあってもよい。
【００８７】
また、第１のビットマップテーブルにおいては、ｓｃａｌｅフラグとｕｓａｂｌｅフラグの両方のビットが必要だが、第２のビットマップテーブルにおいては、ｕｓａｂｌｅフラグのビットのみ必要なので、ブロックに割り当てるビット数を前者は２ビット、後者は１ビットにしてもよい。構造を同じにすれば、処理を共通化できるメリットがあるので、同じビット数を割り当てて、第２のビットマップテーブルではｓｃａｌｅのフラグに相当するビットを使用せず、あるいは別な用途に用いるようにしてもよい。
【００８８】
本実施の形態では、１つのブロックが持つ情報は図３に示すように高々数ビットであるため、ビットマップテーブル全体のサイズは極めて小さく、大容量の記録媒体であっても、媒体全体の使用状況等を高速に取得できる。また、サイズが小さいため、機器のメモリ上に読みこんでもシステムリソースを圧迫しないというメリットがある。
【００８９】
例えば、ＦＡＴファイルシステムでは、データ領域の使用状況等とデータの配置情報が分離されず一体となっており、クラスタチェインを記録した１つの巨大なテーブルとなってしまう。このため、記録時には媒体の空き領域を探すのに時間と手間がかかる欠点があり、再生時もクラスタのリンク情報を辿らなければならず、やはり時間と手間がかかり、いずれも効率的でない。また、ＦＡＴのテーブルは、サイズが大きいためメモリ上でシステムのリソースを圧迫する。２ＧバイトのＦＡＴ１６ファイルシステムでは、ＦＡＴサイズは約１２０ｋバイトにもなる。
【００９０】
これに対し、本実施の形態では、記録時はサイズの小さいビットマップテーブルをサーチして空き領域を探すだけなので、極めて高速に効率良く情報を取得でき、リソースも殆ど消費しない。また、再生時にはビットマップテーブルの参照は不要で、直接ファイルの管理情報から、配置状況を取得できる。
【００９１】
前記２Ｇバイトの例で比較すると、基本ブロックサイズを１.５Ｍバイト、サブブロックサイズをＦＡＴ１６ファイルシステムと同じ３２Ｋバイトとした場合、１つのブロックの状態を表すのに４ビット使用すると仮定すると、第１のビットマップテーブルの本体部分は僅か６８０バイト程度となり、ＦＡＴファイルシステムの１８０分の１である。第２のビットマップテーブルは、１つにつきテーブル部分が２４バイトと、これも非常に小さい。
【００９２】
本実施の形態においては、全体の使用状況を示すサイズの小さい第１のビットマップテーブルがあるため、全体の状況を素早く取得することが出来、必要に応じて参照される第２のビットマップテーブルは、まとめて配置することができるため、サブブロックの状況も素早く取得することができる。
【００９３】
次に、本発明のブリッジファイルシステムの一実施の形態における第１及び第２のビットマップテーブルの一例について説明する。図４は第１のビットマップテーブルの一例を示し、図５は第２のビットマップテーブルの一例を示す。
【００９４】
図４の第１のビットマップテーブルおいて、スペース・アロケーション・インフォメーション・デスクリプタ（Ｓｐａｃｅ＿Ａｌｌｏｃａｔｉｏｎ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｄｅｓｃｒｉｐｔｏｒ）は、第１のビットマップテーブルの先頭に位置し、第１のビットマップテーブルであることを示す識別子の他、第１のビットマップテーブル全体のサイズなどの情報が格納されている。
【００９５】
サイズオブＬＣ（Ｓｉｚｅ＿ｏｆ＿ＬＣ）は、基本ブロックのサイズ、サイズオブマップ（Ｓｉｚｅ＿ｏｆ＿ＭＡＰ）は、ビットマップ本体部分のサイズ、サイズオブＤＳＣ（Ｓｉｚｅ＿ｏｆ＿ＤＳＣ）は、デフォルトのサブブロックサイズ、サイズオブＤＳＣＭＡＰ（Ｓｉｚｅ＿ｏｆ＿ＤＳＣＭＡＰ）は、デフォルトの第２のビットマップテーブルのサイズ、ナンバー・オブ・ブロック（Ｎｕｍｂｅｒ＿ｏｆ＿Ｂｌｏｃｋ：ＮＢ）は、基本ブロックの数、ナンバー・オブ・スモールブロック（Ｎｕｍｂｅｒ＿ｏｆ＿Ｓｍａｌｌ＿Ｂｌｏｃｋ）は、基本ブロックのうち、サブブロックに分割されている基本ブロックの数、ＳＡＩアラインメント（ＳＡＩ＿Ａｌｉｇｎｍｅｎｔ）は、第１のビットマップテーブルをスタッフィングデータによって、５１２バイトの倍数のサイズにした場合のサイズ、ＳＢＩ＿Ｄアラインメント（ＳＢＩ＿ＤＡｌｉｇｎｍｅｎｔ）は、第２のビットマップテーブルをスタッフィングデータによって、５１２バイトの倍数のサイズにした場合のデフォルトサイズ、ベーシック・ブロック・ビットマップ（Ｂａｓｉｃ＿Ｂｌｏｃｋ＿Ｂｉｔｍａｐ）は、サイズがＮＢ／２バイトのビットマップ本体をそれぞれ示す。ベーシック・ブロック・ビットマップの要素の１つが、図３に示すフラグを表す。
【００９６】
図５の第２のビットマップテーブルにおいて、スモール・ブロック・インフォメーション・デスクリプタ（Ｓｍａｌｌ＿Ｂｌｏｃｋ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｄｅｓｃｒｉｐｔｏｒ）は、第２のビットマップテーブルの先頭に位置し、第２のビットマップテーブルであることを示す識別子の他、第２のビットマップテーブル全体のサイズなどの情報が格納されている。
【００９７】
また、ベーシック・ブロック・ナンバー（Ｂａｓｉｃ＿Ｂｌｏｃｋ＿Ｎｕｍｂｅｒ）は、所属する基本ブロックの識別番号、ブロックアドレス（Ｂｌｏｃｋ＿Ａｄｄｒｅｓｓ）は先頭ブロックの論理ブロックアドレス（パーティション先頭を０番地とする論理セクタ単位のアドレス番号）、ＳＢＩアラインメント（ＳＢＩ＿Ａｌｉｇｎｍｅｎｔ）は、スタッフィングデータによって、５１２バイトの倍数のサイズにした場合のサイズで、第１のビットマップテーブルにおける、ＳＢＩ＿ＤＡｌｉｇｎｍｅｎｔと異なる場合、このＳＢＩ＿Ａｌｉｇｎｍｅｎｔの方を優先する。
【００９８】
サイズオブＬＣ（Ｓｉｚｅ＿ｏｆ＿ＬＣ）は、対応する基本ブロックのサイズ、サイズオブＳＣ（Ｓｉｚｅ＿ｏｆ＿ＳＣ）はサブブロックサイズで、第１のビットマップテーブルにおけるサイズオブＤＳＣと異なる場合は、このサイズオブＳＣの方を優先する。サイズオブＳＣＭＡＰ（Ｓｉｚｅ＿ｏｆ＿ＳＣＭＡＰ）は、第２のビットマップテーブルのサイズで、第１のビットマップテーブルにおけるサイズオブＤＳＣＭＡＰと異なる場合は、このサイズオブＳＣＭＡＰの方を優先する。
【００９９】
また、ナンバーオブＳＣ（Ｎｕｍｂｅｒ＿ｏｆ＿ＳＣ：ＮＳＣ）は、この基本ブロック内に含まれるサブブロックの数、スモール・クラスタ・ビットマップ（Ｓｍａｌｌ＿Ｃｌｕｓｔｅｒ＿Ｂｉｔｍａｐ）は、サイズがＮＳＣ／２バイトのビットマップ本体を示す。スモール・クラスタ・ビットマップの要素の１つ１つが、図３に示すフラグを表す。ただし、図３のＳｃａｌｅフラグは無効なフラグである。
【０１００】
第１のビットマップテーブルは、媒体全体又は媒体がパーティションに分割されている場合はパーティション全体に対して１つ存在する。なお、安全性を高めるために、内容が同一なコピーを別に用意してもよい。第２のビットマップテーブルは、サブブロックに分割された基本ブロック毎に存在するので、０個から基本ブロックの個数までいろいろな場合がある。コピーを用意する場合は、コピーに応じた数だけ増加する。
【０１０１】
第１のビットマップテーブルには、第２のビットマップテーブルに関するデフォルトのサイズのパラメータがいくつか用意されており、サブブロックに分割する際のガイドラインとして使用することができる。第２のビットマップテーブルのパラメータを常にこのデフォルト値に従って作成することにより、第２のビットマップテーブルの管理がより容易になる。
【０１０２】
一方、すべてのパラメータをデフォルト値に合わせなくても、第２のビットマップテーブルのパラメータを優先するようにしたので、基本ブロック単位でサブブロックの利用方法を独自に設定することができ、記録するファイルの性質に応じたダイナミックな運用が可能である。例えば、ある基本ブロックと別な基本ブロックで、サブブロックのサイズを異なる値に設定することができる。どのような使い方をするかは、アプリケーションが自由に設定してよい。
【０１０３】
本発明によるブリッジファイルシステムは記録するデータを限定するものではないが、特定の用途のアプリケーションに関連するデータを記録するのに特に適している。このような例の１つとして、映像や音声をリアルタイムで記録し、プレイリストを使って通常再生し、サーチ情報を使って特殊再生するようなアプリケーションがある。
【０１０４】
ＡＶのストリームデータは、一般にサイズが大きく、リアルタイム性が要求されるため、本発明における基本クラスタ単位での記録再生に最適である。また、プレイリストやサーチのための情報など、ＡＶのストリーム以外のデータはＡＶデータと比較してサイズがはるかに小さいために、サブブロックに記録するのに最適である。また、基本ブロック単位に記録するファイルであっても、最終ブロックを有効に使用するため、最終ブロックのみサブブロックに分割してもよい。
【０１０５】
このようなアプリケーションでは、サイズの大きいデータと小さいデータが別に存在することが予めわかっているため、フォーマット時に記録媒体をいくつかの領域に分け、例えば基本ブロック単位で使用する領域とサブブロック単位で分割して使用する領域の２つに分けてもよい。このように、予め領域を定めて使用すると、基本ブロック中にサブブロックに分割されたエリアが存在しないため、混在した場合よりも基本ブロック単位の外部フラグメンテーションが発生しにくい。ただし、ファイルの最終部分が格納される。基本ブロックについては、元々データ境界であるため、基本ブロックとして利用する領域であっても、例外的にサブブロックに分割し、空き領域を効率的に使用してもよい。
【０１０６】
このように、予め領域を定める場合は、使用中に領域の過不足が生じる可能性があるので、任意の領域を拡大、縮小、移動、挿入、削除、コピーなどの操作によってダイナミックに変更できるようにするとよい。
【０１０７】
ＡＶストリームデータは、データの信頼性よりもリアルタイム性が要求され、一方プレイリストやサーチのための情報などは、データの信頼性の方が重要なので、前記分割した領域に対して、予めエラー発生時のリカバリー方法を個別に設定するとよい。
【０１０８】
例えば、ＡＶストリームデータを記録再生する基本ブロック単位の領域は、エラー発生時のリトライを行わないものとし、プレイリストやサーチのためのデータを記録再生するサブブロック領域は、ある程度のリトライを許すことによって、データの性質に応じた最適な記録再生が行える。
【０１０９】
このようなエラー発生時の対応方法を設定した情報は、管理情報としてフォーマット時に記録媒体に保存しておくか、後から必要に応じて設定変更する。また、記録媒体がハードウェア的にそのような仕組みに対応している場合は、その仕組みに合わせた手続によって対応方法の設定もしくは参照を行うことにより、エラー発生に対応すればよい。
【０１１０】
次に、本発明におけるサブブロックの活用方法について説明する。サブブロックの活用方法には、サイズの小さいファイルへの適用のほか、欠陥領域への適用がある。記録媒体は、一般に初期不良あるいは使用中の不良発生によって欠陥領域が発生することがある。ＦＡＴファイルシステムにおいては、このような欠陥領域はクラスタ単位で欠陥であることを示し、使用しないようにする。従って、たとえ１セクタの不良であっても、クラスタ全体が使用不能になってしまう。このため、クラスタサイズが大きくなればなるほど、欠陥セクタのために無駄になる領域が増えてしまい、記録媒体の使用効率が下がってしまう。
【０１１１】
これに対して、本発明においては欠陥領域が存在する場合、これを含む基本ブロックをサブブロックに分割することで、無駄になる領域をサブブロック内にとどめることができる。さらに、サブブロックのサイズは基本ブロック毎に独自に設定することができるため、該当基本ブロックにおけるサブブロックのサイズを論理セクタサイズと等しくすることにより、無駄な領域を完全になくすことも可能である。
【０１１２】
また、基本ブロック全体が欠陥領域である場合は、その基本ブロックはサブブロックには分割せず、第１のビットマップテーブルの該当する基本ブロックに対応するｄｅｆｅｃｔフラグをセットする。
【０１１３】
また、サブブロックに分割すると正常なサブブロックがある場合は、その基本ブロックはサブブロックに分割して使用し、第２のビットマップテーブル内でサブブロック毎に欠陥領域があるかどうかをｄｅｆｅｃｔフラグに反映する。
【０１１４】
記録媒体によっては、ＤＶＤ−ＲＡＭのようにデバイスが欠陥管理機能を持っていて、欠陥領域を正常領域に自動的にマッピングし直すものがある。このように正常領域にマッピングされた領域のことを交替領域と呼ぶ。交替領域の存在は一般にアプリケーションからは見えないため、連続領域にアクセスしているつもりでも物理的には不連続にアクセスしていることがある。
【０１１５】
本発明では、基本ブロックを物理的に連続する領域で構成することによってＨＤＤなどにおけるヘッドシークを避け、ＡＶストリームなどのリアルタイムアクセスが必要な用途に最適に使用できることを可能にしている。従って、ＡＶストリームに使用する場合は、基本ブロック内に交替セクタが存在しない方がよい。サブブロックについては、そのような制約はないので交替領域があってもよい。
【０１１６】
従って、ＡＶストリームの記録再生を目的とする場合は、記録媒体上に交替セクタがある時は、前記交替セクタを含む基本ブロックをサブブロックに分割して使用することで、基本ブロック単位で使用する場合には交替セクタが存在しないことを保証することができる。なお、基本ブロック全体が交替セクタになっていて、交替領域が連続しているならそのまま基本ブロックとして使用してもよい。
【０１１７】
次に、予約領域を設定できるという本発明の特徴について説明する。予約した領域であることを示すために、第１、第２のビットマップテーブルともにブロックに対応したプリアロケーテッドフラグを持ち、このフラグがセットされていると、対応する基本ブロックまたはサブブロックが予約領域であることがわかる。従って、別なプロセスが同じ記録媒体を共有して使用している場合であっても、別なプロセスが予約領域を使用することがない。
【０１１８】
また、予約領域は一種の特別なファイル（予約領域ファイルと呼ぶことにする）として登録し、その管理情報にそこに記録するファイルの識別情報（ファイルシステムが使用するファイルの識別番号、あるいはファイル名など）を格納できるようにしておくと、その予約領域がどのファイルの記録のために予約してあるのか判断できる。この管理情報は、領域予約時に指定してもよいし、予約時には単に領域だけ確保し、実際に記録する段階で記録するファイルの識別子をセットしてもよい。
【０１１９】
また、予約領域ファイルは他の通常ファイルと区別できるように、その管理情報として予約領域ファイルであることを示す識別情報をもつようにする。予約領域はファイルとして管理するようにしたので、複数の予約領域を区別して管理することができる。また、予約した領域は予約領域ファイルとして参照できるので、予約する時点ではそこに記録するデータを特定せず領域の確保だけを行い、後で実際にデータを記録する際に、既にある予約領域ファイルを参照することによって確保した予約領域を利用することができる。
【０１２０】
また、予約領域に記録するファイルの管理情報には、予約領域ファイルを特定するための識別情報を格納できるようにする。これによって、予約領域ファイルとそこに記録するファイルの間で相互に参照できるようになる。
【０１２１】
あるファイルにおいて予約領域をセットして記録する場合、基本ブロック単位に記録するファイルの場合は、基本ブロック単位に予約領域を確保し、サブブロック単位に記録するファイルの場合は、サブブロック単位に予約領域を確保する。予約領域のサイズは、予約領域を確保する際に同時に指定するようにする。
【０１２２】
あるいは、指定したサイズが基本ブロックより大きいか小さいかによってどの単位で予約領域を確保するかを決めてもよい。例えば、指定したサイズが基本ブロックより大きい場合には基本ブロック単位の予約領域とし、小さい場合はサブブロック単位の予約領域としてもよい。この時、予約したブロックに対応するプリアロケーテッドフラグを予約領域としてセットする。
【０１２３】
予約領域にデータを記録中に予約領域が足りなくなりそうな場合、予約領域の残りサイズが予め定めた量以下になると、予約領域を拡張する。予約領域を拡張する場合、拡張するサイズは予め定めたサイズ、または予約領域に作成時に決定したサイズ、または予約領域に記録するファイルをオープンした時点で決定したサイズのいずれかで拡張するものとし、そのサイズは基本ブロックまたはサブブロックの倍数とする。
【０１２４】
拡張する予約領域は、現在の予約領域の直後以降で利用可能な最初の基本ブロックまたはサブブロックから確保する。従って、基本ブロック単位で拡張する場合は、第１のビットマップテーブルを検索して、予約領域より後の利用可能な最初の基本ブロックを探す。
【０１２５】
サブブロック単位で拡張する場合は、予約領域が所属するサブブロックの第２のビットマップテーブル内に予約領域より後の利用可能なサブブロックがあるかを検索し、そこにない場合、あるいはそれでは不足する場合、次に利用可能な基本ブロックを第１のビットマップテーブルから検索し、そこをサブブロックに分割した上で先頭から順に予約領域として確保するか、サブブロックに分割した基本ブロックを第１のビットマップテーブルから探し、その中で利用可能な最初のサブブロックを探して確保する。
【０１２６】
もし、確保した領域よりも後に新たに確保する領域が見つからない場合は、媒体の先頭に戻って、空き領域を探す。予約領域ファイルは、後で予約領域を追加する場合の追加領域サイズを管理情報として持つことができる。追加領域サイズがない場合、あるいは特に指定しない場合は、基本ブロックまたはサブブロックの数倍のあらかじめ定めた単位で拡張するようにする。
【０１２７】
このように、本実施の形態では、予約領域にデータを記録している際に、予約領域が不足した場合、適切なサイズで予約領域を拡張できるようにしたので、最初の予約領域サイズが不充分であっても、外部フラグメンテーションの発生を最小限に抑えながら、動的に対応できる。
【０１２８】
他方、予約領域が余った場合、余った領域をそのまま残しておいてもよいし、解放してもよい。どちらにするかは、予め予約領域を作成する時点、あるいは、予約領域への記録を開始する時点で決めてもよいし、記録するファイルをクローズする時点で決めてもよい。
【０１２９】
解放する場合は、ビットマップ上のプリアロケーテッドフラグをリセットし、予約領域ファイルを削除する。そのまま残す場合は、ビットマップ上のプリアロケーテッドフラグと予約領域ファイルを残ったエリアに対応するように修正する。残った予約領域を利用して前記ファイルに追加書きこみをする場合は、前記ファイルには前記予約領域ファイルの識別情報があるので、これを参照することによって直ちに記録する場所の情報を取得できる。
【０１３０】
このように、本実施の形態では、予約領域にデータを記録している際に、記録終了時に予約領域が余った場合、その領域をそのまま予約領域として残しておくか、あるいは解放するかを、指定することができるので、例えば後から追加記録する可能性が大きい場合は、将来の記録に備えてそのまま予約領域を残し、追加記録する可能性が低い場合は、予約領域を開放して、媒体の空き領域を増やすような運用ができる。
【０１３１】
次に、本発明のＡＶストリームへの適用例として、ＭＰＥＧ２のトランスポートストリーム（ＴＳ）とプログラムストリーム（ＰＳ）の両方に適用可能な実施の形態について説明する。
【０１３２】
ＴＳは主に放送系に使用される１８８バイトのパケットサイズのストリームである。ＴＳはパケットの到着時刻によってデコーダのシステムクロックを管理するので、ＴＳパケットを記録する場合は、到着時刻におけるシステムのカウンタの値をタイムスタンプとしてパケットに付加して記録する方法がＤＶＨＳ等で一般に行われている。タイムスタンプやその他の付加情報を含めたパケットサイズは一般に１９２バイトである。
【０１３３】
一方、ＰＳは主にＤＶＤ等の蓄積系に使用され、パケットサイズは可変であるが、ＤＶＤの場合、光ディスクのセクタサイズ（２０４８バイト）との親和性から２０４８バイトが一般に使用される。このサイズはＨＤＤで一般に用いられるセクタサイズ５１２バイトの整数倍（４倍）であるため、ＨＤＤとも同様に親和性がよい。すなわち、光ディスクには１セクタに１パケット記録可能で、ＨＤＤには４セクタに１パケットを記録可能である。ＨＤＤの場合は４セクタをセットで扱うことによって容易に１パケットを扱うことが可能である。
【０１３４】
これに対し、ＴＳは１９２＝２６×３より、因数に３を含んでいるため、ＨＤＤや光ディスクにＴＳパケットを記録すると、パケットが２つのセクタにまたがる個所が発生する。一つのパケットは連続して記録再生することが望ましいが、一般にはパケットが分割される場所で外部フラグメンテーションが発生する可能性がある。
【０１３５】
例えば、ＦＡＴファイルシステムでは、連続しないクラスタにまたがってパケットが配置される可能性がある。ＦＡＴファイルシステム以外のファイルシステム、例えば光ディスクに用いられるＵＤＦ（Universal Disk Format）などではクラスタという概念は無く、ディスク上の連続セクタ領域（エクステント）毎に記録しており、各エクステントのサイズには制約がないため、エクステントの境界で、パケットの分割が発生する可能性がある。
【０１３６】
これを避けるためには、ＰＳの場合は１個のパケットを複数個の連続するセクタで記録し、ＴＳの場合は複数個の連続するパケットを複数個の連続するセクタで記録するための制約を与える必要がある。
【０１３７】
そこで、ＴＳとＰＳで一般的に用いられるパケットサイズ１９２バイトと２０４８バイトの最小公倍数である６１４４バイト（＝６ｋバイト；１ｋバイトは１０２４バイト）の倍数を基本ブロックのサイズとすると、ＴＳ、ＰＳいずれのパケットを記録する場合でもパケットが２つの基本ブロックをまたがることがないので、基本ブロック単位の外部フラグメンテーションが発生しても問題ない。
【０１３８】
次に、配置されたデータ（ファイル）を配置方法に関わり無く、共通の構造で管理する方法について説明する。前述したように、２種類のブロックサイズ（すなわち、基本ブロックとサブブロックの各ブロックサイズ）に応じた２種類のビットマップテーブルを持つことは、これによって記録媒体の使用状況を効率良く検索できるので、特に記録時に必要なブロックサイズの空き領域を素早く取得するのに有効である。以下では、再生時のファイルへのアクセス方法について説明する。
【０１３９】
本発明では、基本ブロックに格納されたファイルであっても、サブブロックに格納されたファイルであっても、あるいは、両者をどのように組み合わせて格納されたファイルであっても、同一の形式、手続きでアクセスすることができるため、サブブロックに格納されたファイルへのアクセスが不利になることはない。
【０１４０】
このため、本発明では、媒体上のデータを連続するセクタに配置されたデータの塊の集合として扱っている。このデータの一塊のことを一般にエクステントと呼び、一般に用いられているデータの管理形式の一つである。
【０１４１】
図６は本発明におけるファイル管理情報の一例を示す。ファイル管理情報は、ファイル本体と１対１に対応する一種のファイルである。同図において、ファイル・インフォメーション・ブロック・デスクリプタ（File_Information_Block_Descriptor）は、ファイル管理情報であることを示す識別子の他、ファイル管理情報全体のサイズなどの情報が格納されている。
【０１４２】
また、ファイル・インフォメーション（Ｆｉｌｅ＿Ｉｎｆｏｒｍａｔｉｏｎ）は、ファイル名、タイムスタンプ、アクセス属性などの各種属性、ファイルサイズ等が格納される。また、ナンバーオブエクステント（Ｎｕｍｂｅｒ＿ｏｆ＿Ｅｘｔｅｎｔ：ＮＥ）はエクステントの数、ファイルエクステント（Ｆｉｌｅ＿Ｅｘｔｅｎｔ）はＮＥ個のエクステントの並びである。
【０１４３】
エクステントの表現形式はいろいろあるが、基本的にはエクステント先頭データの媒体上のアドレスと、エクステントのサイズの組み合わせで表す。本発明の一実施の形態では、エクステントの先頭アドレスとしてパーティション先頭からの論理ブロックアドレスを用いているが、論理セクタアドレス等、媒体上の位置を特定できるアドレス情報であれば何を用いてもよい。また、エクステントサイズは、論理ブロック単位に丸めた値を用いているが、実際に使用しているバイト数を用いてもよい。論理ブロック単位に丸めた値を用いる場合は、ファイル・インフォメーションに格納されたファイルサイズから正確なバイト数を得ることができる。
【０１４４】
図７は本発明になる記録媒体の一実施の形態の記録情報の説明図を示す。同図において、記録媒体は同一サイズの基本ブロック毎に論理的に分割されており、データ領域の先頭から昇順に識別番号が割り当てられている。図７はその一部を取り出した例で、丸数字で示す４から１７までの基本ブロックと、その一部の拡大図を示している。基本ブロックのうち、丸数字の１３と１６はどちらも１２個の同一サイズのサブブロックに分割してある。
【０１４５】
なお、サブブロック数は１２個以外の数であってもよく、また基本ブロック毎に違う数であってもよい。また、サブブロックの取り扱いを容易にするために、基本ブロック内をすべて等サイズのサブブロックに分割することが望ましいが、基本ブロック内の最終ブロックのサイズが異なることを禁止するものではない。
識別情報としては、基本ブロックの位置が特定できれば十分であり、上記のように基本ブロック毎に昇順につけられた識別番号を利用する場合は、基本ブロックのサイズと識別番号の積で、基本ブロックの開始位置が特定できる。基本ブロックの開始セクタアドレスと終了セクタアドレス（またはサイズ）を直接用いれば計算しなくても直ちに位置を特定できる。
【０１４６】
また、図７において、ファイルａとファイルｂは基本ブロック単位に記録した大きいサイズのデータである。このうち、ファイルａは３つの連続する基本ブロック（丸数字５、６、７）に配置されているため、１つのエクステントＥａ１で構成されているが、ファイルｂは２つのエクステントＥｂ１とＥｂ２に分かれており、ここで基本ブロック単位の外部フラグメンテーションが発生している。なお、ファイルｂの最終部分は、領域を有効活用するためにサブブロックに分割されている。
【０１４７】
ファイルｃとファイルｄは、サブブロック単位に記録した小さいサイズのデータである。ファイルｃは丸数字１３で示す基本ブロック中のサブブロックの識別番号７〜９の３つの連続するサブブロックに配置されているため、１つのエクステントＥｃ１で構成されている。これに対し、ファイルｄは丸数字１６で示す基本ブロック中の識別番号０〜３までの連続するサブブロックからなるエクステントＥｄ１と、識別番号７と８のサブブロックからなるエクステントＥｄ２の計２つのエクステントに分かれて配置されているため、ここでサブブロック単位の外部フラグメンテーションが発生している。以上をまとめると、表１に示すようになる。
【０１４８】
【表１】
なお、図７の例では説明のためにファイルを分割して媒体上にばらばらに配置したが、通常の使用時に空き領域がある場合は、できるだけ連続する領域に配置するように運用する。
【０１５０】
一つのファイルの配置情報はエクステントによって管理する。ファイルが媒体上で複数のエクステントに分かれている場合は、エクステント情報の並び（リスト）によって、その配置状態を表す。エクステントの情報は、エクステント先頭データの媒体上のアドレスと、エクステントのサイズの組み合わせで表す。一般に媒体へのアクセスは論理ブロック単位で行われるため、ファイルの先頭は論理ブロックの先頭から配置される。
【０１５１】
従って、通常、前記アドレスは論理ブロックアドレスなどのブロック単位のアドレスで表記される。また、サイズについても同じ理由から論理ブロック単位で指定されることが多い。論理ブロックのサイズは媒体によって異なり、一般にＨＤＤやメモリデバイス等では５１２バイト、光ディスク系では２０４８バイトが用いられる。実際のデータサイズは、論理ブロック以下の端数がでるため、最終論理ブロックについては、ファイル全体のサイズから有効データサイズを取得する。エクステントのサイズとしてバイト単位で指定するようにした場合は、全体のサイズ情報が無くても直接有効なデータサイズを取得することができる。
【０１５２】
図７において、４つのファイルａ〜ｄの配置情報を取り出してまとめると、表２に示すようになる。
【０１５３】
【表２】
【０１５４】
図６と対応付けると、Ｓ＊はファイル・インフォメーション（Ｆｉｌｅ＿Ｉｎｆｏｒｍａｔｉｏｎ）内に格納される情報、Ｎ＊はナンバーオブエクステント（Ｎｕｍｂｅｒ＿ｏｆ＿Ｅｘｔｅｎｔ：ＮＥ）、（Ａ＊，Ｅ＊）はファイル・エクステント（Ｆｉｌｅ＿Ｅｘｔｅｎｔ）［ＮＥ］である。
【０１５５】
図６の別な例として、Ｆｉｌｅ＿Ｅｘｔｅｎｔ［ＮＥ］の最後の要素の後に、最後のエクステントであることを示すターミネイト識別子を置いてもよい。この場合、ナンバーオブエクステントがなくてもすべてのエクステントがわかるので、ナンバーオブエクステントを省略してもよい。また、ファイル・インフォメーション・ブロック・デスクリプタ内に、この管理情報全体のサイズを格納しておけば、ナンバーオブエクステントも前記ターミネイト識別子も省略することができる。あるいは、すべての情報を省略することなく格納することで、管理情報全体の信頼性を向上させることもできる。
【０１５６】
ターミネイト識別子を置く場合、通常のエクステント情報と同じ構造で、通常のエクステントと区別できるものを予め決めておけば何でもよい。例えば、エクステントのサイズが０のエクステントは存在しないので、Ｅ＊＝０のエクステント情報をターミネイト識別子とすることができる。あるいは、エクステント情報毎にフラグを用意して、最終エクステントかどうかを明示してもよい。
【０１５７】
このように、ファイルの配置情報は、ファイルの配置場所に関わり無く同じ形式で表現されるため、基本ブロックに配置されたファイルでも、サブブロックに配置されたファイルでも同じ手続きでアクセスすることができるため、どちらかのアクセス効率が不利になることはない。また再生時は、前記エクステント情報だけを用いてファイルの配置情報を取得でき、ビットマップテーブルを参照する必要はない。
【０１５８】
次に、配置済みのファイルが実際にどのように２つのビットマップテーブルで表現されているかを、図７の例を使って説明する。図８は図７に対応する第１のビットマップテーブルの例である。この例では、ブロックの状態を表す管理情報として、図３に示した例のうち、スケール（ｓｃａｌｅ）とユーザブル（ｕｓａｂｌｅ）の２ビットだけを用いた。この２ビットは第１のビットマップテーブルを構成するための最低必要な要素である。
【０１５９】
図８は各ブロックに対応する各フラグがどの状態になっているか分かり易いようにテーブルで表現してある。ｓｃａｌｅフラグは１の時に基本ブロック単体として使用していることを示し、０の時にサブブロックに分割してあることを示す。従って、図８のｓｃａｌｅフラグより、図７に丸数字１３と１６で示した２つの基本ブロックがサブブロックに分割してあることがわかる。また、図８のｕｓａｂｌｅフラグは、ｓｃａｌｅフラグに対応する未使用のブロックがあるかどうか（使用可能かどうか）を示すフラグであって、１のときｓｃａｌｅフラグに対応した未使用のブロックがあることを示す。
【０１６０】
従って、例えば、ブロック４は基本ブロックとして割り当ててあり１バイトも使用していない。ブロック５は基本ブロックとして使用中であることを示している。また、図７では、ブロック７は基本ブロックとして使用しており、まだ空き領域はあるが、この部分はもう基本ブロックとしては新たに使用できない（既にあるデータへの追記録しかできない）ので、ブロック５と同じように扱われる（ｕｓａｂｌｅ＝０）。
【０１６１】
一方、ブロック１３は基本ブロックに割り当てられたファイルｂの最終部分が格納されるブロックであるが、ブロック７と異なりサブブロックに分割してある。図７の拡大図を見ると、この部分はサブブロックの先頭の３ブロックしか使用していないため、ブロック７と異なり残りの９個のサブブロックを他のデータの記録用に使用することができる。
【０１６２】
図７の例では、実際にサイズＳｃのファイルｃを基本ブロック１３の中の７、８及び９番目のサブブロックに記録している。ファイルｃを記録した後でも、基本ブロック１３の中の３〜６番目と１０、１１番目のサブブロックは未使用なので、サブブロックとして利用可能なブロックが存在する（ｕｓａｂｌｅ＝１）。
【０１６３】
図９はサブブロックに分割した基本ブロック１３の第２のビットマップテーブル（ビットマップ本体のみ）を示す。図７に示したように、基本ブロック１３は、サブブロック０、１、２がファイルｂの最終部分によって使用され、サブブロック７、８、９がファイルｃによって使用されているので、図９に示す第２のビットマップテーブルは、サブブロック０、１、２、７、８、９が使用されていることを、ｕｓａｂｌｅ＝０で示している。
【０１６４】
図９ではサブブロックの状態を管理するフラグとしてはｕｓａｂｌｅの１ビットだけを示した。この１ビットが第２のビットマップテーブルを構成するための最低必要な要素である。同様に、図１０には基本ブロック１６の第２のビットマップテーブルを示す。図７では、基本ブロック１６は、サブブロック０〜３がファイルｄの１番目のエクステントＥｄ１によって使用され、サブブロック７、８がファイルｄの２番目のエクステントＥｄ２によって使用されているので、図１０に示す基本ブロック１６の第２ビットマップテーブルでは、サブブロック０〜３、７及び８が使用されていることを、ｕｓａｂｌｅ＝０で示している。
【０１６５】
ビットマップデータの実際のデータは、ブロック毎のフラグをブロック番号順に並べて求める。図１１は第１のビットマップのデータの求め方を示している。ブロック毎に（ｂｉｔ１，ｂｉｔ０）＝（ｕｓａｂｌｅ，ｓｃａｌｅ）とフラグを並べ、これを１バイトの中でＬＳＢ側からブロック順に詰めていってデータを作成する。図１１ではバイト内でブロック順に詰める操作は、左側をＭＳＢにしているため並べ替え操作になる。
【０１６６】
＃を１６進数を表すものとすると、最終的なデータは、順に♯ＦＦ，♯５７，♯ＤＦ，♯Ｆ９，♯ＦＥ，・・・となる。第２のビットマップテーブルも同様に求めると、ブロック１３は、♯７８，♯ＦＣ、ブロック１６は♯７０，♯ＦＥとなる。なお、２バイト目は下位４ビットのみ有効である。この例ではサブブロックは１２に分割してあり、管理情報のフラグがブロックにつき１ビットしかないので基本ブロック１つにつき１２ビットのテーブルサイズになる。
【０１６７】
図１２は基本ブロック１３、１６のビットマップデータを取得する手順を示す。図６に示したフィル管理情報内の情報の１つであるファイルインフォメーション（Ｆｉｌｅ＿Ｉｎｆｏｒｍａｔｉｏｎ）には、前記ファイルサイズ以外にもいくつかの情報がある。図１３は、このファイルインフォメーションの一例である。同図において、ファイルＩＤ（Ｆｉｌｅ＿ＩＤ）は、パーティション内でファイルまたはディレクトリに固有な識別番号である。本発明におけるファイルシステムは、ディレクトリはそのデータ構造が予め規定されたファイルとして扱うので、デイリクトリにもＦｉｌｅ＿ＩＤがある。
【０１６８】
ルートディレクトリのＦｉｌｅ＿ＩＤは予め定めた特定の値、例えば０に予約されているものとする。ルートディレクトリを初めとする、すべてのディレクトリには、そのディレクトリに所属するファイル又はディレクトリのＦｉｌｅ＿ＩＤが格納されているので、ルートディレクトリ以下の階層構造を、ディレクトリの内容を辿ることによって取得できる。
【０１６９】
また、図１３中、ディレクトリＩＤ（Ｄｉｒｅｃｔｏｒｙ＿ＩＤ）は、このファイルまたはディレクトリが所属しているディレクトリのＦｉｌｅ＿ＩＤを格納する。この情報を参照することによって、下位のディレクトリ階層にあるファイルからルートディレクトリまで逆に辿ることができる構造になっている。
【０１７０】
また、ターゲットＩＤ（Ｔａｒｇｅｔ＿ＩＤ）は、このファイルが予約領域ファイルである場合、この予約領域に記録するファイルのＦｉｌｅ＿ＩＤを格納する。また、このファイルが予約領域に記録する通常ファイルである場合、予約領域ファイルのＦｉｌｅ＿ＩＤを格納する。
【０１７１】
また、ファイルフラグ（Ｆｉｌｅ＿Ｆｌａｇｓ）は、後述するファイルの各種属性を表すフラグ群である。タイムスタンプ（Ｔｉｍｅ＿Ｓｔａｍｐ）は、このファイルに関する各種時刻情報であり、作成日時、最終更新日時、最終アクセス日時、削除した日時などを格納する。ファイルサイズ（Ｆｉｌｅ＿Ｓｉｚｅ）は前記ファイルサイズである。更に、ファイルネーム（Ｆｉｌｅ＿Ｎａｍｅ）は、このファイルを参照するための名称である。キャラクタコードやサイズについては本発明では特に規定しない。
【０１７２】
上記のＦｉｌｅ＿Ｆｌａｇｓには、少なくとも表３に示す３つのフラグを持つ。すなわち、バリッド（Ｖａｌｉｄ）、デリーテッドファイル（Deleted File）及びプリアロケーテッド・エリア（Preallocated Area）である。
【０１７３】
【表３】
【０１７４】
表３に示したバリッドフラグは通常１で、そのファイルまたはディレクトリが有効であることを示す。あるファイルを消去する場合は、通常、そのエントリに対するファイル管理情報を完全に消去すると同時に、ビットマップテーブルで該当ファイルが占める領域を空き領域に変更する必要があるが、本発明では、ファイル管理情報を削除する際に、そのエントリを完全に消去してしまう以外の方法として、前記バリッドフラグを０にすることによって、この管理情報が無効であることを表すようにしている。これによって、管理情報のサイズが大きかった場合でも、前記フラグだけを０にすればよいので、ファイルの消去が容易に行える。
【０１７５】
また、ファイルを削除した後で削除を取り消したい場合があるので、表３に示したデリーテッドファイルというフラグをファイル管理情報に設け、一時削除／復活に対応できるようにした。すなわち、デリーテッドファイルが１の時は通常の状態のファイルだが、０にセットすることによって、このファイルが一時削除状態にあることを示す。
【０１７６】
一時削除状態にある場合は、このファイルに対するアクセスは禁止され、通常の手段では、その存在も見えないようにしておく。一時削除ファイルがあるかどうかは、専用のアクセス手段によってその存在が見えるようにしておき、専用の手段によって復活できるようにしておく。一時削除ファイルにアクセスしたい場合は、前記専用の手段によって、通常のファイルに復活してからアクセスするものとする。
【０１７７】
一時削除中のファイルは、それが占めている媒体上の記録スペースを他のファイルによって上書きされないように、その配置情報はそのまま保っておく必要がある。これは単に、第１と第２のビットマップテーブルを、一時削除前の状態のまま変更しないだけでよい。すなわち、一時削除前と後では、前記デリーテッドファイルフラグだけが変更されている。
【０１７８】
フラグを用いて永久に削除する場合の違いは、永久に削除する場合は、バリッドフラグの変更のほかに、ビットマップテーブルのファイル占有領域を開放する点である。永久削除を意味するバリッドフラグを用意することにより、エントリを完全に消去しなくてもこのバリッドフラグをクリアするだけで永久削除と同じ効果が得られ、高速な消去が可能である。
【０１７９】
なお、バリッドフラグを用いた削除の場合でも、削除した直後など、データが上書きされていない場合には、専用の手段を設ければファイルを復活することも可能である。
【０１８０】
プリアロケーテッド・エリアフラグは、このファイルが予約領域ファイルであることを示す。予約領域ファイルは、特定のファイルあるいは、将来何らかのファイルを記録するために予め記録する領域を確保するために設けられた特別なファイルである。プリアロケーテッド・エリアフラグは通常ファイルの場合は０で予約領域ファイルの時に１に設定する。
【０１８１】
予約領域ファイルの配置された領域は予約領域そのものであり、予約領域ファイル自体はデータをもたないため、予約領域ファイル自体はデータを書き込まない。予約領域に書き込むファイルが決まったら、そのファイルＩＤ（Ｆｉｌｅ＿ＩＤ）を、図１３のターゲットＩＤに格納し、予約領域ファイルの先頭からファイルデータの記録を開始する。
【０１８２】
予約領域ファイルの作成は、実際に書き込むファイルをオープンする直前に行ってもよく、この場合は、予約領域ファイルの作成と同時にターゲットＩＤに記録するファイルのファイルＩＤを書き込んでおく。これは、ファイルを書き込みオープンするときに、予約領域サイズを指定してオープンする専用の手続きによって実現することができる。また、予約領域に書き込むファイルのターゲットＩＤには、予約領域ファイルのファイルＩＤを格納し、両者が相互に参照できるようにする。
【０１８３】
予約領域ファイルが占有する領域は、ビットマップテーブル上では、図３のプリアロケーテッドフラグで示され、基本ブロックまたはサブブロック単位で予約領域かどうかを調べることができる。複数の予約領域ファイルや複数の一時削除ファイルを管理するために、例えばルートディレクトリの直下に専用のディレクトリを設け、このディレクトリ内でこれらのファイルを管理すると効率良く管理することができる。
【０１８４】
図１４はディレクトリ内でファイルを管理する一例の説明図を示す。同図において、ルートディレクトリの直下に「ｐｒｅａｌｌｏｃ．ｄｉｒ」という予約領域ファイルを配置する専用のディレクトリがある。このディレクトリには「ａｒｅａ１．ｄａｔ」、「ａｒｅａ２．ｄａｔ」という２つの予約領域ファイルがある。これらはそれぞれ、／ａｖｄａｔａ．ｄｉｒ／ｓａｍｐｌｅ．ｄｉｒ／ａ．ｄｉｒというディレクトリにある「ａ１．ｄａｔ」と／ａｖｄａｔａ．ｄｉｒ／ｓａｍｐｌｅ．ｄｉｒ／ｂ．ｄｉｒというディレクトリにある「ｂ１．ｄａｔ」というファイルに対応している。
【０１８５】
すなわち、「ａｒｅａ１．ｄａｔ」は予約領域ファイルであることを示す、プリアロケーテッド・エリアフラグが１にセットされ、ターゲットＩＤとして、／ａｖｄａｔａ．ｄｉｒ／ｓａｍｐｌｅ．ｄｉｒ／ａ．ｄｉｒ／ａ１．ｄａｔを特定するための情報が格納されており、「ａ１．ｄａｔ」には「ａｒｅａ１．ｄａｔ」を特定するための情報が格納されている。
【０１８６】
また、「ａｒｅａ２．ｄａｔ」は予約領域ファイルであることを示す、プリアロケーテッド・エリアフラグが１にセットされ、ターゲットＩＤとして、／ａｖｄａｔａ．ｄｉｒ／ｓａｍｐｌｅ．ｄｉｒ／ｂ．ｄｉｒ／ｂ１．ｄａｔを特定するための情報が格納されており、「ｂ１．ｄａｔ」には「ａｒｅａ２．ｄａｔ」を特定するための情報が格納されている。
【０１８７】
一般に、階層ディレクトリ精造を持つファイルシステムでは、ファイルはディレクトリの木構造の中で分散してしまうため、それぞれのファイルが予約領域を持つ場合、予約領域の一元管理が難しい。本発明では、予約領域を予約領域ファイルに対応付けることによって複数の予約領域を区別して管理でき、さらにこれを１つのディレクトリでまとめて管理できるようにしたので効率の良い管理が可能になった。
【０１８８】
また、図１４において、「ｄｅｌｆｉｌｅｓ．ｄａｔ」は、一時削除したファイルを特定するための情報をテーブルとして持ち、／ａｖｄａｔａ、ｄｉｒ／２００１．０２．０１．ｄｉｒディレクトリにある、「ｆｉｌｅ２．ｄａｔ」と「ｆｉｌｅ３．ｄａｔ」に関する識別情報が記録されている。「ｆｉｌｅ２．ｄａｔ」と「ｆｉｌｅ３．ｄａｔ」はデリーテッドファイルフラグが０になっており、一時削除状態にある。従って、通常の手続きで／ａｖｄａｔａ．ｄｉｒ／２００１．０２．０１．ｄｉｒディレクトリを見ると、「ｆｉｌｅ１．ｄａｔ」しか見えない。
【０１８９】
なお、この例では、「ｄｅｌｆｉｌｅｓ．ｄａｔ」は／ｄｅｌｅｔｅｄ．ｄｉｒというディレクトリにおいたが、他のディレクトリやルートディレクトリにおいてもよい。例えば、ディレクトリ毎に置くようにして、そのディレクトリ内の一時ファイルのみを管理するようにしてもよい。
【０１９０】
本発明では、このように一時削除ファイルをまとめて管理できるようにしたので、復活したいファイルを検索し、一時削除ファイルを永久に削除することによって記録領域を増やしたい場合など、簡単に一時ファイルを参照することができて都合がよい。
【０１９１】
一時削除したファイルを特定する識別情報のテーブルは、ディレクトリ毎に持ってもよい。図１４の例では、／ａｖｄａｔａ．ｄｉｒ／２００１．０２．０１．ｄｉｒに「ｄｅｌｆｉｌｅｓ．ｄａｔ」をおけばよい。
【０１９２】
着目しているディレクトリ内の一時削除ファイル情報を取得する場合、パーティション全体の一時削除ファイルのリストでは、一つ一つ該当ディレクトリのファイルかどうかをチェックする必要があるが、ディレクトリ毎に一時削除ファイル情報を用意しておけば、これを参照することによって直ちに取得することができる。なお、全体の一時削除ファイルとディレクトリ毎の削除ファイルが両方あってももちろんよい。
【０１９３】
次に、ビットマップテーブルのアラインメントについて説明する。
図１５は第１のビットマップテーブルの記録媒体上の配置例を示す。第１のビットマップテーブル１５１は、その管理情報１５２とテーブル本体１５３から構成される。媒体上に記録する場合は、論理セクタ単位でアラインメントが取れるように、管理情報１５２の直後、またはテーブル本体１５３の直後にスタッフィングのためのダミーデータ１５４を挿入する。
【０１９４】
次に、第２のビットマップテーブルの記録媒体上の配置例について図１６及び図１７と共に説明する。第２のビットマップテーブルは、第１のビットマップテーブルよりサイズが小さく、複数個存在し、その数が使用時に変動するという特徴がある。
【０１９５】
図１６は、１つの第２のビットマップテーブルサイズが論理セクタサイズよりも大きい場合の例であり、第１のビットマップテーブルと同様に第２のビットマップテーブル毎に論理セクタ単位でアラインメントをとるためのダミーデータを付加している。
【０１９６】
また、各ビットマップテーブルは図１６（ａ）に示したように１個１個ばらばらに置いてもよいが、論理セクタ単位のアラインメントをとっているので、同図（ｂ）に示したように隙間無く詰めて配置することができる。この時、第１のビットマップテーブルでの配置の順番に従って第２のビットマップテーブルを順番に並べればサブブロックをまとめて管理するのに都合がよい。
【０１９７】
図１７は、第２のビットマップテーブルのサイズが論理セクタサイズより小さい場合の例で、（ａ）はその数が多くて合計のサイズが論理セクタサイズを超える場合、（ｂ）はその数が少なくて、合計サイズが論理セクタサイズに満たない場合の例である。図１７（ａ）、（ｂ）のどちらの場合も複数個のビットマップテーブルを隙間無く詰めて配置しているが、その際に各ビットマップテーブルが２のべき乗の倍数のバイト数になるようにしておくと、アドレッシングが容易になる。特に２のべき乗の同一サイズに設定すれば、ｎ個目のビットマップテーブルの位置をビットシフト演算だけで求めることができて効率が良い。
【０１９８】
次に、スタッフィングのためのダミーデータの配置方法について、図１８及び図１９と共に説明する。図１８のビットマップテーブルの管理情報１８１には、図４と図５で説明したように先頭のデスクリプタ（Descriptor）の中にビットマップテーブル全体のサイズ１８４が格納されている。また、ビットマップテーブル本体１８２のサイズも同様に格納されている。管理情報部分のサイズは固定なので、ビットマップテーブル本体１８２の後にダミーデータ１８３を付加し、全体のサイズにダミーデータ１８３を含めたサイズを格納すればよい。
【０１９９】
あるいは、管理情報を可変長とし、図１９に１９３で示すように管理情報内に管理情報部分のサイズを格納することにより、管理情報本体１９１の直後にダミーデータ１９２を付加することもできる。このようにすると、ビットマップテーブルの開始アドレスを都合のよい値に設定することができる。
【０２００】
図１８と図１９の方法は組み合わせてもよく、この場合、ビットマップテーブルの開始アドレスを任意の値に設定すると同時に、ビットマップテーブルの全体サイズを論理セクタの倍数に設定することが可能になる。
【０２０１】
次に、ＦＡＴファイルシステムとのブリッジについて説明する。図２０は、ＦＡＴ１２またはＦＡＴ１６ファイルシステムとのブリッジの例を示す。同図において、ＦＡＴファイルシステムのデータ領域はルート（ＲＯＯＴ）ディレクトリの直後以降であり、ファイルシステム＃１のデータ領域もここから始まる。ＦＡＴファイルシステムの先頭クラスタ番号は”２”であり、以後昇順にクラスタ番号が振られている。ファイルシステム＃１は６クラスタを１基本ブロックのサイズとしており、基本ブロック０から昇順に基本ブロックが割り当ててある。
【０２０２】
サブブロックのサイズはクラスタサイズと同じで、サブブロックに分割した基本ブロックについては、クラスタと同様に扱うことができる。同図で基本ブロック０、２、３がサブブロックに分割した基本ブロックである。
【０２０３】
同図では以下の４つの通常のファイルａ〜ｄと管理情報ファイルがあり、ファイルシステム＃１では図２１に示すようにファイル管理情報filectr1で管理されている。このファイル管理情報filectr1は、データ領域の任意の位置に配置できて、図２０では２０１に示すように、基本ブロック３のサブブロック３に格納されているものとする。また、第１のビットマップテーブルに続いて第２のビットマップテーブルが連続して配置され、これは基本ブロック３のサブブロック０に格納されている。なお、図２１の情報は、記録媒体に記録されている図６に示したファイル管理情報を再生することにより直接に得られてメモリに展開される。
【０２０４】
また、ファイルシステム＃１の全体を管理するためのシステム情報Ａ、ＢがＦＡＴファイルシステムのシステム領域の最後２０２、または基本ブロック３のサブブロック２５の領域２０３に配置されている。ここには、ボリューム全体の構造、このパーティションの構造、その他のシステム管理情報へのボインタ等が格納される。これらのデータ領域に配置された管理情報２０１は記録媒体であるディスク上の任意の位置に配置することができるので、記録領域にエラーが発生した場合などに、正常な領域に移動することができる。
【０２０５】
また、これらの管理情報は第２のファイルシステム（ここではＦＡＴファイルシステム）からファイルとして参照できるようになっている。図２２に、ＦＡＴファイルシステム上のファイル管理情報の１つであるディレクトリエントリから関係する情報だけを抜き出して示す。同図において、例えば、ファイルａはファイルサイズがＳａで、クラスタエントリ（ファイルの先頭データが格納されているクラスタ番号）ＣＥａが２であることを示す。つまり、ファイルａはクラスタ番号２番から格納されている。
【０２０６】
同様に、第１及び第２のビットマップテーブルは、ファイルサイズがＳｅで、クラスタエントリＣＥｅが２０であり、ファイル管理情報filectrlは、ファイルサイズがＳｆで、クラスタエントリＣＥｆが２３であり、ファイルシステム＃１のシステム情報sysctrlは、ファイルサイズがＳｇで、クラスタエントリＣＥｇが２５である。
【０２０７】
図２３は、ＦＡＴファイルシステムのもう一つのファイル管理情報であるＦＡＴの例である。同図では、３０個のクラスタエントリ（０〜２９）からなるＦＡＴを示すために、３行１０列の矩形領域で３０個のクラスタエントリを模式的に示している。例えば、ファイルａはクラスタ番号２、３、４に記録されているので、ディレクトリエントリにファイル名と一緒に最初に２番であるという情報が書かれる。また、図２３に示すように、ＦＡＴの２番のエントリを見ると、３と書かれているので、２番に続くデータがクラスタ番号３のクラスタに記録されていることが示されている。
【０２０８】
同様に、ＦＡＴの３番のエントリを見ると、４と書かれているので、３番に続くデータがクラスタ番号４のクラスタに記録されていることが示されており、更に、ＦＡＴの４番のエントリを見ると、Ｅと書かれているので、ファイルａのデータは、このクラスタ番号４番のクラスタで終了することが示されている。このようにして、記録媒体上のファイル配置を知ることができる。コンピュータは、図２２と図２３から抽出した各ファイルのクラスタ番号やクラスタサイズなどに基づいて、図２４に示すようなクラスタチェインを取得して、メモリ上に展開する。
【０２０９】
以上のように、ファイルシステム＃１からは、図２１の情報を介して、ＦＡＴファイルシステムからは図２４の情報を介して、同一のファイルにアクセスすることができる。
【０２１０】
また、ＦＡＴ３２ファイルシステムにおいては、ＲＯＯＴディレクトリが通常のデータ領域に置かれる。通常はデータ領域の先頭（クラスタ２）から配置されるが、必須条件ではないので、図２５に示すようにデータ領域の途中に配置してもよい。また、ＲＯＯＴディレクトリのサイズが足りなくなったら増やすことができるため、フラグメントが発生する場合もある。
【０２１１】
図２５に示すように、ＲＯＯＴディレクトリがデータ領域に配置される場合は、クラスタ単位で任意の位置に境界がくる可能性があるため、ＲＯＯＴディレクトリを含む基本ブロックでは、サブブロックに分割して使用することによって、余ったサブブロックの領域をデータ記録用に使用することができる。図２５では、ＲＯＯＴディレクトリを含む基本ブロック０、１をサブブロックに分割することによって、基本ブロック０のサブブロック０，１，２，３，４と基本ブロック１のサブブロック２，３，４，５を他のデータの記録に用いることができる。
【０２１２】
次に、ＮＴＦＳとのブリッジについて説明する。第２のファイルシステムとしてＮＴＦＳを用いる場合も、ＦＡＴ３２ファイルシステムと同様な構成にすることができる。このとき、ＭＦＴ（Master File Table）の扱いを、図２５に示したＲＯＯＴディレクトリの扱いと同じようにすればよい。
【０２１３】
次に、ＩＳＯ９６６０、ＵＤＦとのブリッジについて説明する。ＩＳＯ９６６０やＵＤＦは特定のセクタを起点として、記述子（descriptor）の集合として管理構造が配置され、各記述子にボリュームやファイルの構造が格納されている。
【０２１４】
ＩＳＯ９６６０では、図２６に示すようにボリューム記述子集合（ＶＤ）に続いてパステーブル（ＰＴ）が配置される。ＶＤにはボリューム構造に関する情報などが格納され、パステーブル（ＰＴ）にはすべての階層ディレクトリへのエントリが格納されている。これを参照することによって、ＲＯＯＴディレクトリから辿らなくても下位のディレクトリに直接アクセスすることが可能になっている。ファイルの配置情報自体は、前記第１のファイルシステムと同じエクステントによる形式であるため、ブリッジ構造をとることは、比較的容易である。
【０２１５】
図２７はＵＤＦの概要を示す図である。ＵＤＦでは、ボリューム構造に関する情報などはメイン・ボリューム・ディスクリプタ・シーケンス（ＭＶＤＳ：Main Volume Descriptor Sequence）中に格納される。ＭＶＤＳは、ポインタであるＡＶＤＰ（Anchor Volume Descriptor Pointer）によって参照される。
【０２１６】
ＭＶＤＳには、パーティションの位置やファイル集合記述子の場所などが格納されており、これを参照することによって、データエリアの場所とルートディレクトリの場所がわかる。ルートディレクトリにはファイル毎にＦＩＤというファイルの識別情報を示す記述子がある。
【０２１７】
ＦＩＤにはファイルの配置情報が直接記述してあるわけではなく、代わりにＩＣＢ（Information Control Block）と呼ばれる、ファイルのサイズ、配置、属性等の情報を記述したファイルを指している。実際のファイルへのアクセスはこのＩＣＢを通して間接的に行われる。これは、書換えを最小限にするために導入されたＵＤＦの特徴の一つである。ファイルに対する変更が行われると、これに対応するＩＣＢだけを変更すればよく、このファイルを含んだディレクトリの情報は書換える必要がないので、書換えの影響が上位のディレクトリに波及しないという特徴がある。
【０２１８】
以上のように、ＵＤＦの場合はファイル構造を管理するために、ファイル毎にＩＣＢというファイルが必要である。これらはファイルサイズが小さく、パーティション内の任意の位置に配置できるという特徴があるので、第１のファイルシステムと共存させる場合はこれらの管理情報をできるだけまとめて、サブブロックに分割した領域に配置するとよい。
【０２１９】
図２８は、第１のファイルシステムとＩＳＯ９６６０、ＵＤＦの３つのファイルシステムを共存させた本発明のブリッジファイルシステムの一実施の形態を示す。この実施の形態では、ルートディレクトリ以外のＩＣＢを一ケ所に集めてサブブロックに配置している。また、ＩＳＯ９６６０や、ＵＤＦにおけるファイル構造を管理するための情報である、ＰＴ（Path Table）や、ルートディレクトリ、ＩＣＢを含む基本ブロックはサブブロックに分割し、またサイズの小さいファイルもサブブロックに配置している。これらのＩＳＯ９６６０やＵＤＦの管理情報は、それぞれ又はいくつかをまとめて第１のファイルシステムからファイルとして参照することができる。
【０２２０】
同図において、基本ブロック０、１、２、４がサブブロックに分割した基本ブロックである。１つのサブブロックには、２個以上のファイルが入らないように運用する。ただし、ＩＣＢについてはサイズが小さく同じ形式のファイルであることから、同図に示したように、基本ブロック１のサブブロック０に連続して配置することによって、ファイルシステム＃１から見た場合は１つのファイルのように扱ってもよい。各ＩＣＢはＵＤＦから見るとたまたま連続して配置してあるだけであって、実際にはそれぞれ論理的に独立している。
【０２２１】
また、ファイルシステム＃１の管理情報であるビットマップテーブルは第１のビットマップテーブルに続いて第２のビットマップテーブルを連続して配置し、同図では、基本ブロック１のサブブロック２に配置されており、ファイルシステム１からもＵＤＦ、ＩＳＯ９６６０からも参照できる。同様に、ファイルシステム＃１のファイル管理情報が基本ブロック１のサブブロック３に、ファイルシステム＃１のシステム情報が基本ブロック１のサブブロック５に配置されており、どのファイルシステムからも参照できる。
【０２２２】
本発明は、記録領域のデータファイルに対し、第１と第２の両方のファイルシステムからアクセス可能にするブリッジファイルシステムであるが、すべてのデータファイルが両方のファイルシステムから参照できる必要はない。これは、他のファイルシステムからそのファイルに対してアクセスして欲しくない場合などに適用することができる。相互参照を行わないことによって、他のファイルシステムからはそのファイルの存在する隠蔽することができる。
【０２２３】
例えば、第１のファイルシステムからのみアクセスしたいファイルは、そのファイルの管理情報は第１のファイルシステムにのみ登録し、第２のファイルシステムには登録せず、その配置領域は少なくとも新たな記録には使用できないという情報を登録する。これによって、第２のファイルシステムがその領域を別なデータで上書きしてしまうことを避けることができる。逆の場合も同様である。
【０２２４】
データファイルだけでなく、ファイルシステムの管理情報についても相互に参照できるようにしてもよい。例えば、既に説明したように、第１のファイルシステムの管理情報を第２のファイルシステムからファイルとして参照できるだけでなく、第２のファイルシステムの管理情報を第１のファイルシステムからファイルとして参照できるようにすることもできる。
【０２２５】
管理情報を相互参照する場合、１つの管理情報を１つのファイルシステムに対応付けるのではなく、複数の管理情報をまとめて１つのファイルとして扱うようにしてもよい。管理情報についても、データファイルと同様に、相互参照が必須というわけではなく、参照する必要が無かったり、あるいは参照を禁止したい場合などは、特定の管理情報を相互参照できないようにしてもよい。
【０２２６】
【発明の効果】
以上説明したように、本発明によれば、以下の数々の特長を有する。
【０２２７】
（１）第１のファイルシステムを用意することで、リアルタイム記録再生が要求されるサイズの大きいＡＶストリームを基本ブロックに記録し、確実性が要求されるサイズの小さいＡＶストリームの管理情報などのファイルをサブブロックに記録するのに最適なファイルシステムを実現できる。
【０２２８】
（２）新しい第１のファイルシステムが搭載されていないコンピュータシステムにおいても、記録されたファイルにアクセスできるように、第２のファイルシステムを搭載して、第１及び第２のファイルシステムのどちらからもアクセスできるようにしたので、第２のファイルシステムとして、コンピュータシステムに標準的に搭載されているファイルシステムを採用すれば情報交換が容易にできる。
【０２２９】
（３）第２のファイルシステムとして、リムーバブルの記録媒体におけるデファクトスタンダードであるＦＡＴファイルシステムを採用したので、ほとんどすべてのコンピュータシステムで利用できる。
【０２３０】
（４）第２のファイルシステムとしてＮＴＦＳを採用したので、ＦＡＴファイルシステムを使用する場合よりも高度な管理が可能になる。
【０２３１】
（５）第２のファイルシステムとして、サブブロック単位でなく論理セクタ単位に管理できる。
【図面の簡単な説明】
【図１】本発明のブリッジファイルシステム及び記録媒体の一実施の形態の概略説明図である。
【図２】 本発明の記録媒体の記録領域の先頭付近の利用状況の一実施の形態を示す図である。
【図３】 本発明のブリッジファイルシステムにおけるブロック毎の管理情報を示すための各種フラグの定義例を示す図である。
【図４】 第１のビットマップテーブルの一例を示す図である。
【図５】 第２のビットマップテーブルの一例を示す図である。
【図６】 本発明におけるファイル管理情報の一例を示す図である。
【図７】 本発明になる記録媒体の一実施の形態の記録情報の説明図である。
【図８】 図７に対応する第１のビットマップテーブルの例を示す図である。
【図９】サブブロックに分割した基本ブロックの第２のビットマップテーブル（ビットマップ本体のみ）を示す図である。
【図１０】図７の基本ブロックの第２のビットマップテーブルを示す図である。
【図１１】第１のビットマップのデータの求め方を示した図である。
【図１２】図７の２つの基本ブロックのビットマップデータを取得する手順を示した図である。
【図１３】 ファイルインフォメーションの一例を示す図である。
【図１４】 ディレクトリ内でファイルを管理する一例の説明図である。
【図１５】 第１のビットマップテーブルの記録媒体上の配置例である。
【図１６】 ビットマップテーブルサイズが論理セクタサイズよりも大きい第２のビットマップテーブルの記録媒体上の配置例を示す図である。
【図１７】 ビットマップテーブルサイズが論理セクタサイズよりも小さい第２のビットマップテーブルの記録媒体上の配置例を示す図である。
【図１８】 スタッフィングのためのダミーデータの配置方法を説明するための図である。
【図１９】 管理情報内に管理情報部分のサイズを格納できるようにした図である。
【図２０】ＦＡＴ１２またはＦＡＴ１６ファイルシステムとのブリッジの例を示す図である。
【図２１】ファイルシステム＃１のファイル配置情報の例である。
【図２２】ＦＡＴファイルシステム上のファイル管理情報の１つであるディレクトリエントリから関係する情報だけを抜き出して示した図である。
【図２３】 ＦＡＴファイルシステムのもう一つのファイル管理情報であるＦＡＴの例を示す図である。
【図２４】図２２と図２３から抽出した各ファイルのクラスタチェインを示す図である。
【図２５】ＦＡＴ３２ファイルシステムにおいて、ＲＯＯＴディレクトリがデータ領域の途中に置かれることを示す図である。
【図２６】ＩＳＯ９６６０の概要を示した図である。
【図２７】 ＵＤＦの概要を示した図である。
【図２８】ＩＳＯ９６６０とＵＤＦとのブリッジを示した図である。
【図２９】 ＦＡＴファイルシステムの構造を説明するための図である。
【図３０】 代表的なファイルシステムの容量とクラスタサイズの関係を示す図である。
【図３１】 特開平８−１０１７８３号公報記載の従来のファイルシステムの一例の構成図である。
【図３２】 外部フラグメンテーションと内部フラグメンテーションを示す図である。
【符号の説明】
１００ 記録媒体
１８１ ビットマップテーブルの管理情報
１８２ ビットマップテーブル本体
１８３、１９２ ダミーデータ
１９１ 管理情報本体
１９３ 管理情報全体のサイズ
Claims (7)
- 記録媒体上の連続する記録領域を複数の論理セクタから構成される一定サイズの基本ブロック毎に分割し、該基本ブロック単位でデータを配置して管理する第１の管理方法と、
任意の前記基本ブロックを各々同一サイズの複数の論理セクタから構成される複数のサブブロックに分割し、そのサブブロック単位でデータを配置して管理する第２の管理方法を持ち、前記第１及び第２の管理方法のうち選択した管理方法でデータを記録再生する第１のファイルシステムと、前記記録領域を前記サブブロックと同一サイズのブロック単位でデータを配置して管理する第２のファイルシステムとが共存するブリッジファイルシステムであって、
前記記録領域のデータファイルに対し、前記第１及び第２のファイルシステムの両方からアクセス可能な管理構造を有し、
前記第１のファイルシステムは、前記記録領域内の前記基本ブロック毎の状態を表すフラグの集合とその管理情報が記録された第１のビットマップテーブルを前記記録領域上に配置し、前記サブブロックに分割された前記基本ブロックは、その基本ブロック内のサブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブルを該当する基本ブロック毎に対応付けて前記記録領域上に配置し、前記第２のファイルシステムの管理情報のうち、前記第１のファイルシステムが参照可能な前記記録領域に配置される管理情報がある場合は、前記第１のファイルシステムの前記サブブロックのエリアに配置し、
前記第２のファイルシステムは、前記第１及び第２のビットマップテーブルをファイルとして参照可能で、前記第２のファイルシステムにおけるブロック毎の使用状態とファイルの配置状態を管理する第３のテーブルを持つことを特徴するブリッジファイルシステム。 - 前記第２のファイルシステムはＦＡＴファイルシステムであり、前記第３のテーブルはファイルアロケーションテーブル（ＦＡＴ）であることを特徴とする請求項１記載のブリッジファイルシステム。
- 前記第２のファイルシステムはＮＴＦＳファイルシステムであり、前記第３のテーブルはマスターファイルテーブル（ＭＦＴ）であることを特徴とする請求項１記載のブリッジファイルシステム。
- 前記第１のファイルシステムは、前記記録領域内の前記基本ブロック毎の状態を表すフラグの集合とその管理情報が記録された第１のビットマップテーブルを前記記録領域上に配置し、前記サブブロックに分割された前記基本ブロックは、その基本ブロック内の前記サブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブルを該当する基本ブロック毎に対応付けて前記記録領域上に配置し、
前記第２のファイルシステムは、前記第１及び第２のビットマップテーブルをファイルとして参照可能で、前記第２のファイルシステムの管理情報のうち、前記第１のファイルシステムのデータエリアに配置される管理情報がある場合は、前記第１のファイルシステムの前記サブブロックのエリアに配置し、前記記録領域のデータファイルに対し、前記第１及び第２のファイルシステムの両方からアクセス可能な管理構造を有することを特徴とする請求項１記載のブリッジファイルシステム。 - 前記第２のファイルシステムは、ＩＳＯ９６６０またはＵＤＦであることを特徴とする請求項４記載のブリッジファイルシステム。
- 記録媒体上の連続する記録領域を複数の論理セクタから構成される一定サイズの基本ブロック毎に分割し、該基本ブロック単位でデータを配置して管理する第１の管理方法と、
任意の前記基本ブロックを各々同一サイズの複数の論理セクタから構成される複数のサブブロックに分割し、そのサブブロック単位でデータを配置して管理する第２の管理方法を持ち、前記第１及び第２の管理方法のうち選択した管理方法でデータを記録再生する第１のファイルシステムと、前記記録領域を前記サブブロックと同一サイズのブロック単位でデータを配置して管理する第２のファイルシステムとが共存するブリッジファイルシステムをコンピュータに搭載したコンピュータシステムであって、
前記記録領域のデータファイルに対し、前記第１及び第２のファイルシステムの両方からアクセス可能な管理構造を有し、
前記第１のファイルシステムは、前記記録領域内の前記基本ブロック毎の状態を表すフラグの集合とその管理情報が記録された第１のビットマップテーブルを前記記録領域上に配置し、前記サブブロックに分割された前記基本ブロックは、その基本ブロック内のサブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブルを該当する基本ブロック毎に対応付けて前記記録領域上に配置し、前記第２のファイルシステムの管理情報のうち、前記第１のファイルシステムが参照可能な前記記録領域に配置される管理情報がある場合は、前記第１のファイルシステムの前記サブブロックのエリアに配置し、
前記第２のファイルシステムは、前記第１及び第２のビットマップテーブルをファイルとして参照可能で、前記第２のファイルシステムにおけるブロック毎の使用状態とファイルの配置状態を管理する第３のテーブルを持つブリッジファイルシステムをコンピュータに搭載したことを特徴とするコンピュータシステム。 - 記録媒体上の連続する記録領域を複数の論理セクタから構成される一定サイズの基本ブロック毎に分割し、該基本ブロック単位でデータを配置して管理する第１の管理方法と、
任意の前記基本ブロックを各々同一サイズの複数の論理セクタから構成される複数のサブブロックに分割し、そのサブブロック単位でデータを配置して管理する第２の管理方法を持ち、前記第１及び第２の管理方法のうち選択した管理方法でデータを記録再生する第１のファイルシステムと、前記記録領域を前記サブブロックと同一サイズのブロック単位でデータを配置して管理する第２のファイルシステムとが共存するブリッジファイルシステムを用いたデータ管理方法であって、
前記第１及び第２のファイルシステムは、前記第１のファイルシステムに基づき前記記録領域に記録された第１のデータファイルと前記第２のファイルシステムに基づき前記記録領域に記録された第２のデータファイルのいずれに対しても、それぞれアクセス可能であり、
前記第１のデータファイルを、前記基本ブロック毎の状態を表すフラグの集合とその管理情報とからなる第１のビットマップテーブル、又は前記サブブロック毎の状態を表すフラグの集合とその管理情報が記録された第２のビットマップテーブルが、前記基本ブロック単位又は前記サブブロック単位で記録されたテーブル領域と、データが前記基本ブロック単位又は前記サブブロック単位で記録されたデータ領域とが分離された構造とし、
前記第１及び第２のビットマップテーブルの前記フラグの集合には、そのビットマップテーブルにより管理する前記第１のデータファイル中のデータ領域に、専用のアクセス手段によってのみアクセス可能な一時削除ファイルが記録されていることを示す第１のフラグと、予め記録する領域を確保するために特別に設けられた予約領域ファイルが確保されていることを示す第２のフラグとを含み、
前記第１及び第２のビットマップテーブルにより、前記データ領域に記録するデータを管理することを特徴するブリッジファイルシステムを用いたデータ管理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002185681A JP4221959B2 (ja) | 2002-06-26 | 2002-06-26 | ブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002185681A JP4221959B2 (ja) | 2002-06-26 | 2002-06-26 | ブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004030232A JP2004030232A (ja) | 2004-01-29 |
| JP4221959B2 true JP4221959B2 (ja) | 2009-02-12 |
Family
ID=31181236
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002185681A Expired - Fee Related JP4221959B2 (ja) | 2002-06-26 | 2002-06-26 | ブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4221959B2 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4502375B2 (ja) * | 2004-05-27 | 2010-07-14 | キヤノン株式会社 | ファイルシステムおよびその制御方法 |
| WO2005124530A2 (en) | 2004-06-21 | 2005-12-29 | Kabushiki Kaisha Toshiba | Method for controlling memory card and method for controlling nonvolatile semiconductor memory |
| JP5098145B2 (ja) * | 2005-10-12 | 2012-12-12 | ソニー株式会社 | データ管理装置および記録媒体の管理方法 |
| US8154958B2 (en) | 2005-10-27 | 2012-04-10 | Pioneer Corporation | Recording apparatus using control information and virtual reference information |
| US7599972B2 (en) * | 2006-08-25 | 2009-10-06 | Qnx Software Systems Gmbh & Co. Kg | File system having variable logical storage block size |
| JP5052150B2 (ja) * | 2007-01-29 | 2012-10-17 | 株式会社日立製作所 | ストレージシステム |
| JP5041860B2 (ja) * | 2007-04-20 | 2012-10-03 | 株式会社日立製作所 | ストレージ装置及び管理単位設定方法 |
| JP5335215B2 (ja) * | 2007-10-02 | 2013-11-06 | キヤノン株式会社 | データ記憶装置、データ記憶方法及びプログラム |
| JP5374986B2 (ja) * | 2008-09-17 | 2013-12-25 | 日本電気株式会社 | 携帯端末、サーバおよび保存データ管理方法ならびに通信システム |
| EP2189895A1 (en) * | 2008-11-24 | 2010-05-26 | Deutsche Thomson OHG | Flash based memory comprising a Flash translation layer and method for storing a file therein |
| JP5848594B2 (ja) * | 2011-12-14 | 2016-01-27 | キヤノン株式会社 | 記録装置 |
| JP6361130B2 (ja) | 2013-12-24 | 2018-07-25 | 株式会社ソシオネクスト | ファイルアクセスプログラム、ファイルアクセス方法 |
-
2002
- 2002-06-26 JP JP2002185681A patent/JP4221959B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004030232A (ja) | 2004-01-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7024534B2 (en) | Information recording medium, information recording method, information recording apparatus, information reproduction method, and information reproduction apparatus | |
| JP3607153B2 (ja) | ファイル管理方法及び装置 | |
| JP4801314B2 (ja) | 記憶媒体にデータを保存する又は記憶媒体からデータを読み込む方法及び装置並びに記憶媒体 | |
| JP2004520672A (ja) | シーケンシャルな媒体にファイルを記録する方法及び装置、シーケンシャルな媒体からファイルを読み込む方法及び装置、並びにシーケンシャルな媒体 | |
| WO1997017652A1 (fr) | Appareil et procede de traitement d'informations | |
| WO2005066787A1 (ja) | 情報記録媒体 | |
| JP2004013276A (ja) | ファイルシステム及び記録媒体 | |
| US20080232210A1 (en) | Data Recording/Reproduction for Write-Once Discs | |
| KR20050118731A (ko) | 유니버셜 드라이브장치용 포맷 매핑 방식 | |
| JP4221959B2 (ja) | ブリッジファイルシステム、コンピュータシステム、ブリッジファイルシステムを用いたデータ管理方法及び記録媒体 | |
| US7188147B2 (en) | I/O method and apparatus for optical storage media | |
| JP2000298608A (ja) | コンピュータデータ記憶媒体及びメモリ管理方法 | |
| JP4256075B2 (ja) | ファイルシステム及び記憶領域の管理方法 | |
| WO2001065374A1 (fr) | Procede de gestion de fichiers, enregistreur de donnees l'utilisant, appareil de lecture de donnees, appareil d'enregistrement/lecture de donnees, et disque enregistre au moyen du procede de gestion de fichiers | |
| KR100891088B1 (ko) | 1회 기록 디스크 상에 데이터를 기록하는 방법 및 장치, 및반도체 집적 회로 | |
| JP4585052B2 (ja) | データ記録システム | |
| JP2008269520A (ja) | 記録装置及び記録方法 | |
| US8095576B2 (en) | Recording device | |
| JP4211563B2 (ja) | 再生記録装置 | |
| KR101149593B1 (ko) | 범용 저장 장치를 위한 유연성 있는 포맷팅 | |
| JP2003173285A (ja) | 情報記録方法及び情報記録再生装置 | |
| JP2006048926A (ja) | 情報記録媒体、情報記録方法、情報記録装置、情報再生方法および情報再生装置 | |
| JPH0869400A (ja) | 圧縮データ記録方法 | |
| JP4160334B2 (ja) | 情報記録媒体、情報記録方法、情報記録装置、情報再生方法および情報再生装置 | |
| JP2005032283A (ja) | 記録媒体及びファイル管理方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040930 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071113 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080115 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080819 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080829 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20081008 |
|
| 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: 20081028 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081110 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111128 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121128 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121128 Year of fee payment: 4 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121128 Year of fee payment: 4 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121128 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131128 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |