JPH07262059A

JPH07262059A - ファイル管理方法

Info

Publication number: JPH07262059A
Application number: JP6055376A
Authority: JP
Inventors: Yuichi Suzuki; 雄一鈴木
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 1994-03-25
Filing date: 1994-03-25
Publication date: 1995-10-13

Abstract

(57)【要約】【目的】文字入力手段を持たない機器においても、小
さなメモリ容量で、高速なファイルアクセスを可能にす
る。【構成】データ記録媒体のクラスタを３２セクタによ
り構成し、４セクタにより１つの割当ブロックを構成す
る。ファイルを割当ブロックを最小単位として記録する
ようにする。また、記録媒体には、ビットマップセクタ
とインデックスセクタを設け、ビットマップセクタによ
り、割当ブロックの使用状態を管理する。インデックス
セクタには、インデックスブロックを記録し、各インデ
ックスブロックには、グループタグ、属性コード、タイ
ムスタンプ、ファイルサイズ、エクステント記述子（割
当ブロック数および開始割当ブロック番号）を記録す
る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、例えば、デジタルスチ
ルカメラ等において、記録したデータ（ファイル）を管
理する場合に用いて好適なファイル管理方法に関するも
のである。

【０００２】

【従来の技術】図３２は、従来のファイル管理方法を適
用したデータ記録再生装置の構成例を示す。データ記録
媒体１は、例えば磁気ディスク、光磁気ディスク、ＩＣ
メモリカード等により構成される。媒体駆動部２は、例
えば上記光磁気ディスクに対しては、スピンドルモー
タ、光ピックアップ、サーボ回路、変復調回路等より構
成されるディスクドライブ装置である。

【０００３】メモリ３は、データの記録、再生時におい
て、一時的にデータを記憶するバッファや、各種管理情
報等のワークエリアとして使用される。ＣＰＵ４は、内
蔵するプログラムに従って、媒体駆動部２の制御、メモ
リ３上の管理情報の操作、データ転送等を実行する。

【０００４】データ入力部５は、例えばデジタルインタ
ーフェース、キーボード、Ａ／Ｄコンバータ等により構
成される。データ出力部６は、例えばデジタルインター
フェース、ＣＲＴディスプレイ、Ｄ／Ａコンバータ等に
より構成される。

【０００５】データの記録時においては、データ入力部
５より入力されたデータは、ＣＰＵ４の働きにより、一
旦メモリ３の所定の領域に転送される。次に、ＣＰＵ４
の制御により、媒体駆動部２が動作し、メモリ３上のデ
ータを、データ記録媒体１に記録する。

【０００６】データの再生時においては、ＣＰＵ４の制
御により、媒体駆動部２が動作し、データ記録媒体１に
記録されているデータが、メモリ３の所定の領域に一旦
転送される。次に、ＣＰＵ４の働きにより、メモリ３上
のデータを読み出し、データ出力部６により、出力装置
（図示せず）に出力する。

【０００７】このデータ記録再生装置は、データ記録媒
体１に対し、例えば音楽データであれば複数の曲、静止
画データであれば複数枚の画像など、複数のデータを自
由に記録し、再生し、消去するものである。この機能を
実現するため、このデータ記録再生装置上に、ファイル
システムという機構を設けるのが一般的である。

【０００８】ファイルシステムの代表的な役割は、以下
のとおりである。１．データ記録媒体１の空き領域を管理し、ファイルの
記録に際して、重ね書きによるデータの喪失を防止す
る。２．データ記録媒体１の記録済領域を管理し、ファイル
の再生に際して、そのファイルのデータの記録場所を知
る。３．ファイル識別子を管理し、ファイル識別子によるフ
ァイル（データ）へのアクセスを実現する。

【０００９】このようなデータ記録再生装置のファイル
システムの代表例として、コンピュータシステムにおけ
るディスク装置上のファイルシステムがある。

【００１０】図３３は、ＭＳ−ＤＯＳ（商標）のファイ
ルシステムの構成を略化して表している。ＭＳ−ＤＯＳ
におけるデータ記録媒体１は、ファイルアロケーション
テーブル（以下、ＦＡＴと表す）領域１１、ルートディ
レクトリ領域１２、およびデータ領域１３で構成されて
いる。

【００１１】データ領域１３は、１０２４バイトよりな
る、２乃至Ｎ＋１のＮ個のクラスタにより構成されてい
る。例えば、データ領域１３が１Ｍ（メガ）バイトのデ
ータ記録媒体１は、クラスタ２乃至１０２５クラスタの
１０２４個のクラスタで構成されている。

【００１２】ＦＡＴ領域１１にはＦＡＴが形成され、こ
のＦＡＴは、２乃至Ｎ＋１のＮ個のＦＡＴエントリで構
成されており、１個のＦＡＴエントリ（１２ビット）
は、１個のクラスタに対している。以下に、ＦＡＴの内
容を示す。

【００１３】（１）ＦＡＴエントリの０００は、そのク
ラスタが使用可能であることを示す。（２）ＦＡＴエントリの００２乃至ＦＦ６は、そのクラ
スタにはファイル（データ）が記録されており、そのフ
ァイルは、その番号が示す次のクラスタに続いているこ
とを表す。（３）ＦＡＴエントリのＦＦ８乃至ＦＦＦは、そのクラ
スタにはファイル（データ）が記録されており、それが
ファイルの最終クラスタであることを示す。（４）ＦＡＴエントリのＦＦ７は、そのクラスタが不良
であることを示す。

【００１４】上記ルールに従えば、図３３の例において
は、クラスタ２，４，６よりなる１個のファイルと、ク
ラスタ３よりなる１個のファイルが、データ記録媒体１
に記録されており、クラスタ５およびクラスタ７乃至Ｎ
＋１は、空きとなっている。

【００１５】図３４は、ルートディレクトリ領域１２に
形成されているルートディレクトリの構成図である。ル
ートディレクトリは、それぞれ３２バイトよりなる、０
乃至Ｍ−１のＭ個のディレクトリエントリで構成されて
おり、典型的なＭの値は１１２である。各ディレクトリ
エントリには、ファイル名、ファイル属性、更新日時、
開始クラスタ、ファイルサイズが記録されている。

【００１６】ファイル名の第１バイトの００またはＥ５
は、そのディレクトリエントリが空いていることを表
す。このディレクトリエントリには、ファイル属性とし
て、ディレクトリ属性をなす、特別なファイルを登録す
ることができ、これをディレクトリファイルと呼ぶ（こ
のファイル（データ）自体は、データ領域１３に記録さ
れる）。

【００１７】図３５は、ディレクトリファイルによる、
階層的なファイル管理の例を表している。ルートディレ
クトリにおいては、第１のエントリに、”ＦＩＬＥ１”
のファイル名と、そのデータがクラスタ２（データ領域
１３）に記録されていることが登録されている。第２の
エントリには、”ＦＩＬＥ２”のファイル名と、そのデ
ータがクラスタ３（データ領域１３）に記録されている
ことが登録されている。第３のエントリには、”ＤＩＲ
１”のファイル名と、そのデータがクラスタ４（データ
領域１３）に記録されていることが登録されている。ま
た、ファイル属性として、ディレクトリ属性が記録され
ており、クラスタ４の内容が、ディレクトリファイル
（サブディレクトリ）であることが示されている。

【００１８】クラスタ４（データ領域１３）のディレク
トリファイルにおいては、第１のエントリに、”ＦＩＬ
Ｅ３”のファイル名と、そのデータがクラスタ５（デー
タ領域１３）に記録されていることが登録されている。
第２のエントリには、”ＦＩＬＥ４”のファイル名と、
そのデータがクラスタ６（データ領域１３）に記録され
ていることが登録されている。

【００１９】上記構成によるファイルシステムにデータ
を記録するときは、図３６のフローチャートに示す手順
で行う。

【００２０】ステップＳ３０１で、ＦＡＴを走査し、値
が０００（使用可能）のＦＡＴエントリを、必要個数見
つけ出す。次にステップＳ３０２で、見つかったＦＡＴ
エントリに対応する各クラスタに、データを記録する。
さらにステップＳ３０３では、データを記録したクラス
タに対応する各ＦＡＴエントリに、次のクラスタ番号ま
たはＦＦＦを記録し、データが記録されていることを示
す。

【００２１】次にステップＳ３０４で、ルートディレク
トリ（またはディレクトリファイル）を走査し、空いて
いるディレクトリエントリを見つけ出す。そしてステッ
プＳ３０５で、見つかったそのディレクトリエントリ
に、ファイル名、ファイル属性、更新日時とともに、上
記ステップＳ３０２で記録した最初のクラスタ番号を記
録し、さらにファイルサイズを記録する。

【００２２】上記構成によるファイルシステムからデー
タを再生するときは、図３７のフローチャートに示す手
順で行う。

【００２３】最初に、ステップＳ３２１で、ルートディ
レクトリ（またはディレクトリファイル）を走査し、目
的の（再生対象とされる）ファイル名と一致するディレ
クトリエントリをみつける。次にステップＳ３２２で、
見つかったディレクトリエントリに記録されている開始
クラスタ番号（図３４）を読み、そのクラスタからデー
タを読み出す。ステップＳ３２３では、いまデータを読
み出したクラスタに対応するＦＡＴエントリを読み、ス
テップＳ３２４で、その値を判定する。その値が００２
乃至ＦＦ６（次のクラスタの番号）ならば、ステップＳ
３２５で、次のクラスタからデータを読み出し、ステッ
プＳ３２３に戻り、同様の処理を繰り返す。

【００２４】ＦＡＴエントリの値が、００２乃至ＦＦ６
でないとき、ステップＳ３２６で、ＦＦ８乃至ＦＦＦ
（最終クラスタ）か否かを判定し、そうならば、終了す
る。そうでない場合、ステップＳ３２７で、エラー処理
を行い、終了する。

【００２５】上記構成によるファイルシステムからデー
タを消去するときは、図３８のフローチャートに示す手
順で行う。

【００２６】最初に、ステップＳ３４１で、ルートディ
レクトリ（またはディレクトリファイル）を走査し、目
的の（消去対象とされる）ファイル名と一致するディレ
クトリエントリをみつける。次にステップＳ３４２で、
見つかったディレクトリエントリに記録されている開始
クラスタ番号を読み、対応するＦＡＴエントリの値を得
る。

【００２７】ステップＳ３４３では、そのＦＡＴエント
リに０００（使用可能）を記録し、そのクラスタを使用
可能とする。また、ステップＳ３４４では、ステップＳ
３４２で読み取ったＦＡＴエントリの値が００２乃至Ｆ
Ｆ６（次のクラスタ有）か否かを判定し、次のクラスタ
が存在するのであれば、ステップＳ３４５に進み、次の
ＦＡＴエントリの値を得て、ステップＳ３４３に戻り、
それ以降の処理を繰り返す。

【００２８】ＦＡＴエントリの値が、００２乃至ＦＦ６
ではないとき（次のクラスタが存在しないとき）、ステ
ップＳ３４６に進み、ＦＦ８乃至ＦＦＦ（最終クラス
タ）であるか否かを判定し、そうであったら、ステップ
Ｓ３４７へ移行する。ステップＳ３４７では、ステップ
Ｓ３４１で見つけたディレクトリエントリにおいて、フ
ァイル名の第１バイトにＥ５（空き）を記録して、その
エントリを消去する。ＦＡＴエントリの値が、００２乃
至ＦＦ６でもないときは、ステップＳ３４８に進み、エ
ラー処理を実行する。

【００２９】次に、コンピュータのＯＳのもう１つの代
表例であるＵＮＩＸ（商標）のファイルシステムについ
て説明する。ＵＮＩＸのファイルシステムは非常に複雑
なので、簡略化したモデルにより説明する。

【００３０】図３９は、ＵＮＩＸのファイルシステムの
構成を表している。ＵＮＩＸにおいては、データ記録媒
体１に、ビットマップ領域２１、ｉノードリスト領域２
２、およびデータ領域２３が形成されている。

【００３１】データ領域２３は、それぞれ１０２４バイ
トよりなる、０乃至Ｎ−１のＮ個の論理ブロックで構成
されている。例えば、データ領域２３が１Ｍバイトのと
き、０乃至１０２３の１０２４個の論理ブロックで構成
されている。

【００３２】ビットマップ領域２１に形成されるビット
マップは、各論理ブロックにつき各１ビットよりなる、
Ｎビットのフラグにより構成されており、以下の内容を
示す。

【００３３】（１）フラグの１は、その論理ブロックが
使用可能であることを表す。（２）フラグの０は、その論理ブロックにデータが記録
されているか、不良ブロックであることを表す。

【００３４】図４０は、ｉノードリスト領域２２に形成
されるｉノードリストの構成を表している。ｉノードリ
ストは、２乃至Ｍ＋１のＭ個のｉノードで構成される。
このうち、ｉノード２は、ルートディレクトリのために
確保されている。上記ｉノードは、ファイルのモード
（属性など）、タイムスタンプ、ファイルサイズ、参照
フラグ、直接ポインタ、間接ポインタにより構成されて
いる。

【００３５】参照フラグが１のとき、そのｉノードが使
用されていることを示し、０のとき、空きであることを
示す。

【００３６】直接ポインタには、データが記録された論
理ブロック番号（０乃至Ｎ−１）が記録される。図４０
の例では、０が記録されており、論理ブロック０（直接
ブロック）に、ファイルをなす第１のデータが記録され
ていることを示している。間接ポインタには、間接ブロ
ック番号が記録され、間接ブロックには、データが記録
された論理ブロック番号が記録される。図４０の例で
は、１が記録されており、論理ブロック１が間接ブロッ
クであることを示している。

【００３７】図４０において、間接ブロック（論理ブロ
ック１）には、３個の直接ポインタが記録されており、
第１の直接ポインタは、論理ブロック２にファイルをな
す第２のデータが記録されていることを示し、第２の直
接ポインタは、論理ブロック３にファイルをなす第３の
データが記録されていることを示し、第３の直接ポイン
タは、論理ブロック４にファイルをなす第４のデータが
記録されていることを示している。

【００３８】ＵＮＩＸにおいては、ディレクトリもファ
イルの一種（ディレクトリファイル）とされ、データ領
域２３に記録される。図４１は、このディレクトリファ
イルの構成を表している。ディレクトリファイルは、複
数のディレクトリエントリより構成されており、各ディ
レクトリエントリは、エントリの大きさ、ファイル名の
長さ、ｉノード番号、ファイル名より構成されている。

【００３９】この例では、第１のエントリに、ファイ
ル”ＦＩＬＥ１”が登録されており、そのファイルの諸
情報は、ｉノード３に記録されていることが示されてい
る。第２のエントリには、ファイル”ＦＩＬＥ２”が登
録されており、そのファイルの諸情報は、ｉノード４に
記録されていることが示されている。第３のエントリに
は、ファイル”ＤＩＲ１”が登録されており、そのファ
イルの諸情報は、ｉノード５に記録されていることが示
されている。

【００４０】これを受けて、ｉノード３には、直接ポイ
ンタにより、ＦＩＬＥ１のデータが論理ブロック５に記
録されていることが示されている。また、ｉノード４に
は、直接ポインタにより、ＦＩＬＥ２のデータが論理ブ
ロック６に記録されていることが示されている。さら
に、ｉノード５には、直接ポインタにより、ＤＩＲ１の
データが論理ブロック７に記録されていることが示され
ている。また、ｉノード５のモードは、ファイル”ＤＩ
Ｒ１”がディレクトリファイルであることを示してい
る。

【００４１】論理ブロック７には、ＤＩＲ１の内容（サ
ブディレクトリ）が記録されており、この例では、２つ
のエントリが登録されている。第１のエントリには、フ
ァイル”ＦＩＬＥ３”が登録されており、そのファイル
の諸情報は、ｉノード６に記録されていることが示され
ている。第２のエントリには、ファイル”ＦＩＬＥ４”
が登録されており、そのファイルの諸情報は、ｉノード
７に記録されていることが示されている。

【００４２】これを受けて、ｉノード６には、直接ポイ
ンタにより、ＦＩＬＥ１のデータが論理ブロック８に記
録されていることが示されている。また、ｉノード７に
は、直接ポインタにより、ＦＩＬＥ２のデータが論理ブ
ロック９に記録されていることが示されている。

【００４３】ｉノードによるファイルシステムにデータ
を記録するときは、図４２と図４３のフローチャートに
示す手順で行う。

【００４４】最初にステップＳ３６１で、ｉノードリス
トを走査し、参照フラグ（図４０）が０の未使用ｉノー
ドを得る。次にステップＳ３６２で、そのｉノードに、
ファイルのモード、タイムスタンプ、ファイルサイズを
記録し、参照フラグを１（使用済）とする。さらにステ
ップＳ３６３で、ビットマップを走査し、ビットが１の
未使用論理ブロックを得る。

【００４５】ステップＳ３６４では、その論理ブロック
に対応するビットマップのビットを０（使用済）にし、
ステップＳ３６３で確保した論理ブロックの番号を、ス
テップＳ３６１で得たｉノードの直接ポインタに記録す
る。ステップＳ３６５で、さらに論理ブロックが必要と
判定されたときは、ステップＳ３６６で、ビットマップ
を走査し、ビットが１の未使用論理ブロックをさらに得
る。次にステップＳ３６７で、そのビットマップのビッ
トを０（使用済）にし、ステップＳ３６６で確保した論
理ブロックの番号を、ステップＳ３６１で得たｉノード
の間接ポインタに記録し、間接ブロックとする。

【００４６】ステップＳ３６８では、ビットマップを走
査し、ビットが１の未使用論理ブロックを得る。次にス
テップＳ３６９で、そのビットマップのビットを０（使
用済）にし、ステップＳ３６８で確保した論理ブロック
の番号を、ステップＳ３６７で得た間接ブロックに記録
する。

【００４７】ステップＳ３７０で、さらに論理ブロック
が必要と判定されたときは、ステップＳ３６８に戻り、
必要な数の未使用論理ブロックを得るまで、ステップＳ
３６８とステップＳ３６９を繰り返す。

【００４８】ステップＳ３６５あるいはステップＳ３７
０で、必要な数の論理ブロックが得られたら、ステップ
Ｓ３７１に進み、確保した各論理ブロックに、データを
記録する。さらにステップＳ３７２に進み、ディレクト
リファイルのエントリに、ファイル名とｉノード番号を
記録する。このディレクトリファイルの記録は、ステッ
プＳ３６１乃至Ｓ３７１と同様の処理により行う。

【００４９】ｉノードによるファイルシステムからデー
タを再生するときは、図４４のフローチャートに示す手
順で行う。

【００５０】ステップＳ３８１では、ディレクトリファ
イル（図４１）を走査し、目的のファイル名と一致する
ディレクトリエントリを見つける。次にステップＳ３８
２で、見つかったディレクトリエントリからｉノード番
号を得、ｉノードリストからそのｉノードを読み出す。

【００５１】さらにステップＳ３８３で、そのｉノード
の直接ポインタから、ブロック番号を得、その番号の論
理ブロックからデータを読み出す。次にステップＳ３８
４で、間接ポインタから、ブロック番号を得、その番号
の論理ブロック（間接ブロック）を読み出す。ステップ
Ｓ３８５では、その間接ブロックに記述されている直接
ポインタから、ブロック番号を得、その番号の論理ブロ
ックからデータを読み出す。

【００５２】ｉノードによるファイルシステムからデー
タを消去するときは、図４５と図４６のフローチャート
に示す手順で行う。

【００５３】ステップＳ４０１では、ディレクトリファ
イルを走査し、目的のファイル名と一致するディレクト
リエントリを見つける。ステップＳ４０２では、見つか
ったディレクトリエントリからｉノード番号を得、ｉノ
ードリストからそのｉノードを読み出す。

【００５４】次にステップＳ４０３で、そのｉノードの
直接ポインタから、ブロック番号を得、ビットマップの
そのビットを１（空き）にする。ステップＳ４０４で
は、そのｉノードの間接ポインタから、ブロック番号を
得、その論理ブロック（間接ブロック）を読み出す。ス
テップＳ４０５では、間接ブロックから、ブロック番号
を得、ビットマップのそのビットを１（空き）にする。
さらにステップＳ４０６で、間接ブロックに対応する、
ビットマップのビットを１（空き）にする。

【００５５】次にステップＳ４０７で、ｉノードの参照
フラグを０（未使用）にする。さらにステップＳ４０８
で、ディレクトリファイルから、そのディレクトリエン
トリを削除する。

【００５６】実際のＵＮＩＸファイルシステムでは、論
理ブロックをさらに小さいフラグメントに分割したり、
ｉノードに２重間接、３重間接のポインタを設けるな
ど、さらに複雑な構成としているが、ここでは省略す
る。

【００５７】次に、第３の従来技術の例として、近年オ
ーディオ用として実用化されたＭＤ（ミニディスク）の
構成を説明する。

【００５８】ＭＤに記録されるデータは、トラックとい
う概念で管理され、これは、前記２例のファイルに相当
する。トラックは、必ずしも連続領域に記録する必要は
なく、複数の連続領域の集まりでもよい。この各連続領
域をパーツと呼ぶ。

【００５９】図４７は、ＭＤのデータ記録媒体であるＭ
Ｄディスクの構成を表している。ＭＤディスクは、それ
ぞれ７４７５２バイトよりなる、０乃至Ｎ−１のＮ個の
クラスタで構成され、さらに各クラスタは、２３３６バ
イトよりなる３２個のセクタで構成されている。尚、上
記クラスタ数におけるＮの典型的な値は、約２２００で
ある。

【００６０】上記クラスタのうち、クラスタ３乃至クラ
スタ４９は、ＵＴＯＣ領域とされ、特にクラスタ３のセ
クタ０は、ディスク管理情報が記録される領域とされ、
ＵＴＯＣセクタ０と称される。また、クラスタ５０以降
はユーザー記録領域であり、各ファイルのデータは、こ
の領域に記録される。

【００６１】図４８は、ＵＴＯＣセクタ０の構成を表し
ている。このセクタは、ＦｉｒｓｔＴＮＯ、ＬａｓｔＴ
ＮＯ、Ｐ−Ｅｍｐｔｙ、Ｐ−ＦＲＡ、Ｐ−ＴＮＯ１乃至
２５５、パーツディスクリプタ１乃至２５５により構成
される。

【００６２】ＦｉｒｓｔＴＮＯには、Ｐ−ＴＮＯのう
ち、使用済の最も小さいＰ−ＴＮＯ番号を記録し、Ｌａ
ｓｔＴＮＯには、使用済の最も大きいＰ−ＴＮＯ番号を
記録している。但し、使用済のＰ−ＴＮＯがないとき
は、ＦｉｒｓｔＴＮＯ、ＬａｓｔＴＮＯともに、０が記
録される。

【００６３】Ｐ−Ｅｍｐｔｙには、使用されていないパ
ーツディスクリプタ番号のうちの最初の１つが記録さ
れ、後述の方法（Ｌｉｎｋ−Ｐ）により、使用されてい
ない全てのパーツディスクリプタは、Ｐ−Ｅｍｐｔｙに
連結される。

【００６４】Ｐ−ＦＲＡには、記録されていない領域
（パーツ）を指すパーツディスクリプタ番号のうちの最
初の１つが記録され、後述の方法（Ｌｉｎｋ−Ｐ）によ
り、使用されていない領域を指す全てのパーツディスク
リプタは、Ｐ−ＦＲＡに連結される。

【００６５】各Ｐ−ＴＮＯには、トラック（ファイル）
のデータが記録された領域を指すパーツディスクリプタ
のうち、最初のパーツディスクリプタ番号が記録され、
後述の方法（Ｌｉｎｋ−Ｐ）により、そのトラックのデ
ータが記録された領域を指す全てのパーツディスクリプ
タは、各Ｐ−ＴＮＯに連結される。

【００６６】パーツディスクリプタは、開始アドレス、
終了アドレス、トラックモード、Ｌｉｎｋ−Ｐで構成さ
れている。

【００６７】開始アドレスには、データが記録されたパ
ーツの最初のセクタのアドレスが記録され、終了アドレ
スには、そのパーツの最後のセクタのアドレスが記録さ
れる。トラックモードには、書込禁止／許可、モノラル
／ステレオ等の、データの種別情報が記録される。ま
た、Ｌｉｎｋ−Ｐには、トラックが複数パーツで構成さ
れた場合の、次のパーツディスクリプタ番号が記録さ
れ、もしトラックの最終パーツならば、０が記録され
る。

【００６８】上記構成によるＭＤにデータを記録すると
きは、図４９のフローチャートに示す手順で行う。

【００６９】最初にステップＳ４２１で、Ｐ−ＦＲＡに
リンクされたパーツから、未記録パーツを得る。即ち、
Ｐ−ＦＲＡに記録されている第１のパーツディスクリプ
タを得、そのＬｉｎｋ−Ｐの値（次の空きパーツのパー
ツディスクリプタ番号）をＰ−ＦＲＡに記録することに
より、１つの未記録パーツを得る。この処理は、ステッ
プＳ４２２で、必要な容量が得られたと判定されるまで
繰り返される。

【００７０】ステップＳ４２３では、確保されたパーツ
のうちの最後のパーツが、必要サイズより大きいか否か
を判定し、ＹＥＳのとき、ステップＳ４２４に進み、パ
ーツを分割する。即ち、Ｐ−Ｅｍｐｔｙに記録されてい
る第１の（空きの）パーツディスクリプタを得、そのＬ
ｉｎｋ−Ｐの値（次の空きパーツディスクリプタ番号）
をＰ−Ｅｍｐｔｙに記録することにより、未使用パーツ
ディスクリプタを得、最後のパーツを分割して新たに得
られたパーツのアドレス（開始アドレスと終了アドレ
ス）を、このパーツディスクリプタに記録する。そし
て、最後のパーツ（分割して残されたパーツ）のパーツ
ディスクリプタの終了アドレスを所定値に変更する。

【００７１】次にステップＳ４２５で、ＬａｓｔＴＮＯ
を１増加し、得られたトラック番号のＰ−ＴＮＯに、ス
テップＳ４２１で得られた未記録パーツを連結する。そ
してステップＳ４２６に進み、そのパーツに、データを
記録する。

【００７２】ステップＳ４２３で、パーツが必要サイズ
より大きくないと判定された場合、ステップＳ４２４，
Ｓ４２５の処理は、スキップされる。

【００７３】上記構成によるＭＤからデータを再生する
ときは、図５０のフローチャートに示す手順で行う。

【００７４】最初にステップＳ４４１で、指定されたト
ラック番号のＰ−ＴＮＯから、第１のパーツディスクリ
プタを得、そこに記録されている開始アドレスから終了
アドレスまでを再生する。次にステップＳ４４２で、そ
のパーツディスクリプタのＬｉｎｋ−Ｐが０か否かを判
定し、０でなければ、ステップＳ４４３に進み、次のパ
ーツディスクリプタに記録されている開始アドレスから
終了アドレスまでを再生する。以上の処理を繰り返し、
ステップＳ４４２で、ｌｉｎｋ−Ｐが０と判定されたと
き、処理を終了する。

【００７５】上記構成によるＭＤからデータを消去する
ときは、図５１のフローチャートに示す手順で行う。

【００７６】最初にステップＳ４６１で、指定されたト
ラック番号のＰ−ＴＮＯから、パーツディスクリプタを
得る。次にステップＳ４６２に進み、得られたパーツデ
ィスクリプタに記録されているパーツを、Ｐ−ＦＲＡに
連結する。即ち、Ｐ−ＦＲＡに連結されている各パーツ
ディスクリプタを走査し、最後のパーツディスクリプタ
のＬｉｎｋ−Ｐに、ステップＳ４６１で得たパーツディ
スクリプタ番号を記録し、連結されたパーツディスクリ
プタのＬｉｎｋ−Ｐは０とする。

【００７７】そのトラックに連結されていたパーツを全
てＰ−ＦＲＡに連結したとステップＳ４６３で判定され
るまで、ステップＳ４６１，Ｓ４６２の処理を繰り返し
た後、ステップＳ４６４に進み、その（消去対対象とさ
れる）Ｐ−ＴＮＯより後の全てのＰ−ＴＮＯを１つ前に
移動して、そのＰ−ＴＮＯを消去し、ＬａｓｔＴＮＯを
１減じる。

【００７８】

【発明が解決しようとする課題】ところで、上述した従
来技術には、以下のような問題点があった。

【００７９】前記第１の従来例のＭＳ−ＤＯＳ及び第２
の従来例のＵＮＩＸでは、次のような問題点がある。

【００８０】（１）各データの記録に際し、ファイル名
が定義されることを前提にしているため、デジタルスチ
ルカメラなど、キーボードを持たない機器への適用が困
難である。

【００８１】（２）ファイルの階層的管理のためにディ
レクトリファイルを必要とするなど、管理情報が大き
く、メモリ容量に余裕のない機器への適用が困難であ
る。

【００８２】（３）ディレクトリファイルがデータ記録
領域に記録され、またＵＮＩＸにおいては、ｉノードの
間接ブロックもデータ記録領域に記録されるなど、ファ
イル管理情報がデータ記録領域に散在することになり、
シークの遅いディスク等では、速度低下の問題が生じ
る。

【００８３】（４）ファイルの生成や消去に伴って、デ
ィレクトリファイルの更新や拡張が必要となり、速度低
下の問題が生じる。

【００８４】一方、第３の従来例のＭＤにおいては、フ
ァイル名が不要なため、上記（１）の問題はなく、また
管理情報が小さいため、上記（２）乃至（４）の問題点
もない。しかしながら、以下のような問題点があった。

【００８５】（５）ファイルを階層的に管理する機構が
ない。

【００８６】（６）パーツ数が、２５５個に限られてお
り、多数のファイルを管理できない。

【００８７】（７）本来は各トラックごとの情報である
トラックモードが、全てのパーツディスクリプタに記録
されるなど、管理情報の効率が悪い。

【００８８】本発明はこのような状況に鑑みてなされた
ものであり、これらの問題点を解消することができるよ
うにするものである。

【００８９】

【課題を解決するための手段】本発明のファイル管理方
法は、多数のブロックに区分した領域にファイルを記録
し、再生するようにした記録媒体のファイルを管理する
ファイル管理方法において、記録媒体に、ブロックの使
用状態を表す使用情報を記録するブロック管理領域（例
えば図２のビットマップセクタ０乃至３）を形成すると
ともに、ファイルの記録に使用されたブロックに関する
インデックス情報を記録するインデックス領域（例えば
図２のインデックスセクタ０乃至２５０）とを形成し、
インデックス領域に、ファイルを関連づける関連情報を
記録することを特徴とする。

【００９０】この関連情報は、ファイルをグループに分
類して管理するグループタグ、親のファイルを特定する
番号を記録するインデックスタグ、あるいは、連続する
インデックス領域を特定する情報を記録するリンクタグ
を含むようにすることができる。

【００９１】リンクタグに連続するインデックス領域を
特定する情報が記録されているか否かを表すリンクフラ
グをさらに関連情報に含ませることもできる。さらに、
１つのファイルを管理する複数のインデックス領域のう
ち、先頭のインデックス領域であるか否かを表す拡張フ
ラグを含ませることもできる。

【００９２】また、複数のインデックス領域に記録され
た情報によりインデックスページを形成し、インデック
スページの１ページ分の情報を記憶することができるペ
ージバッファメモリを複数ページ分設け、ページバッフ
ァメモリを管理する情報を記憶するページタグを形成
し、ページタグに、インデックスページを特定する番
号、ページバッファメモリを指定するポインタ、ページ
バッファメモリの内容が更新されたか否かを表す更新情
報の少なくとも１つを記録するようにすることができ
る。

【００９３】また、記録媒体に、インデックスページに
おける未使用インデックス領域の数を表すページアカウ
ントを記録するページアカウント領域を形成することが
できる。この場合、記録媒体のページアカウント領域よ
り読み出したページアカウントを記憶するページアカウ
ントテーブルをメモリに形成するようにすることができ
る。

【００９４】さらに、インデックスブロックには、属性
コードとして、ディレクトリファイルであるか否かを表
すコードを記録し、ディレクトリファイルのデータとし
て子ファイルのインデックス番号を記録し、子ファイル
のインデックスブロックには、インデックスタグとし
て、ディレクトリファイルのインデックス番号を記録す
ることができる。

【００９５】また、ディレクトリファイルのデータとし
て、子ファイルのインデックス番号とともに、子ファイ
ルの名称を記録したり、属性コードを、複数の種類のデ
ィレクトリファイルのいずれかを表す複数ビットのコー
ドで構成することができる。

【００９６】

【作用】上記構成のファイル管理方法においては、イン
デックス領域にファイルを関連付ける関連情報が記録さ
れる。従って、ファイル名がなくとも、多数のファイル
を階層的に管理することが可能になる。また、管理情報
の効率化を図ることができる。

【００９７】

【実施例】

〈実施例１〉以下、図面を参照し、本発明の実施例につ
いて説明する。

【００９８】尚、本発明のファイル管理方法が適用され
るデータ記録再生装置は、図３２に示した従来の場合と
基本的に同様の構成を有しているので、その説明は省略
するが、ファイル管理の仕方が従来の場合と異なってい
る。

【００９９】図１は、本実施例で使用するデータ記録媒
体（ＭＤディスク（データ））１（以下、必要に応じ、
単にＭＤデータと記す）の物理的な構成図（フォーマッ
ト）を表している。ＭＤデータは、６５５３６バイトよ
りなる０乃至Ｎ−１のＮ個のクラスタで構成されてい
る。現時点における、Ｎの典型的な値は約２２００であ
り、また、将来にわたってさらなる大容量化が期待でき
る。上記各クラスタは、それぞれ２０４８バイトよりな
る０乃至３１の３２個のセクタで構成されている。

【０１００】このＭＤデータに対する書き込みは、クラ
スタを最小単位として行う必要があり、読み出しは、セ
クタを最小単位として行う必要がある。

【０１０１】本実施例においては、ファイルへの領域割
当の最小単位をセクタ４個（勿論、それ以上、またはそ
れ以下とすることも可能である）により構成し、割当ブ
ロックと名付ける。また、全クラスタ０乃至Ｎ−１にお
ける割当ブロックに通し番号を付け、割当ブロック番号
とする。

【０１０２】図２は、ＭＤデータの論理的な構成図であ
る。クラスタ０，２，４，６，８，１０，１２，１４の
計８クラスタは、管理クラスタとされ、ファイルの管理
情報を記録する。また、クラスタ１，３，５，７，９，
１１，１３，１５は予備管理クラスタとされ、管理クラ
スタと同一の情報を記録し、万一のデータ喪失に備え
る。残りのクラスタ１６乃至Ｎ−１は、全てデータの記
録領域として使用する。

【０１０３】管理クラスタ０乃至７を構成する各セクタ
を管理セクタと称する。管理セクタ０は、ボリューム情
報セクタとされ、割当ブロックサイズ、ディスク容量等
の、各種パラメータが記録される。

【０１０４】管理セクタ１，２，３，４は、ビットマッ
プセクタ（ビットマップセクタ０乃至３）とされ、アロ
ケーションマップが記録される。アロケーションマップ
は、各割当ブロックにつき各１ビットよりなる、全６５
５３６ビット（＝２０４８バイト×４）で構成され、ビ
ットが０のとき、その割当ブロックが使用可能であり、
ビットが１のとき、使用済であることを表す。従って、
６５５３６個の割当ブロック、即ち、８１９２クラスタ
（＝５１２Ｍ（メガ）バイト）まで管理可能である。但
し、数値＄ＦＦＦＦは、空き判定等に使用するため、ブ
ロック番号としての使用が禁止される。その結果、管理
可能な最大割当ブロック数は、６５５３５個となる。

【０１０５】管理セクタ５乃至３１，６４乃至９５，１
２８乃至１５９，・・・は、インデックスセクタ０乃至
２５０とされ（管理セクタ３７乃至６３，９６乃至１２
７，・・・は、予備のインデックスセクタ０乃至２５０
とされ）、各ファイルの管理情報を記録する。

【０１０６】各インデックスセクタは、各１６バイトよ
りなる１２８個のインデックスブロック（以下、ＩＢと
呼ぶ）により構成される。インデックスセクタ０乃至２
５０における計３２１２８個のＩＢには、０乃至３２１
２７のＩＢ番号が付けられる。

【０１０７】図３は、ＩＢの構成例を示している。その
第１の要素は、グループタグであり、２バイトで構成さ
れる。このグループタグの値が＄ＦＦＦＦのとき、ＩＢ
が空きであることを示す。第２の要素は属性コードであ
り、２バイトで構成される。第３の要素は更新日時等の
タイムスタンプであり、４バイトで構成される。第４の
要素はファイルサイズであり、４バイトで構成される。
第５の要素はデータの位置を示すエクステント記述子で
あり、４バイトで構成される。

【０１０８】エクステント記述子は、割当ブロック数と
開始割当ブロック番号により構成される。２バイトで示
される割当ブロック数は、ファイルデータが記録された
領域の大きさを割当ブロックの数で示し、２バイトの開
始割当ブロック番号は、ファイルデータの記録開始位置
（ファイルの先頭の割当ブロックの番号）を示す。

【０１０９】上述したＭＳ−ＤＯＳにおけるディレクト
リエントリのうち、ファイル名を除く全ての要素を、１
６バイトのＩＢに保持することができる。

【０１１０】このようなＭＤデータに、データを記録す
るときは、図４と図５のフローチャートに示す手順で行
なう。

【０１１１】最初にステップＳ１で、記録媒体１上の管
理クラスタ０乃至７（図２）の内容を、メモリ３上に読
み込む。次にステップＳ２で、メモリ３上のインデック
スセクタ０乃至２５０を走査し、ステップＳ３で、空き
ＩＢ（グループタグ＝＄ＦＦＦＦのＩＢ）があるか否か
を判定し、あると判定されたら、ステップＳ５に進み、
グループタグ（例えば、その属するグループの番号）と
属性コード（例えば、ディレクトリ属性なら１、データ
属性なら０）を記録して、ＩＢを確保する。空きＩＢが
なければ、ステップＳ４に進み、エラーとして終了す
る。

【０１１２】次にステップＳ６で、メモリ３上のアロケ
ーションマップ（ビットマップセクタ０乃至３）（図
２）を走査し、ステップＳ７で、必要な個数の連続する
空き（グループタグ＝＄ＦＦＦＦの）割当ブロックを見
つけたか否か判定し、見つかったら、ステップＳ８に進
み、そのビットを１（使用済）にして、確保する。見つ
からなければ、ステップＳ４に進み、エラーとして終了
する。

【０１１３】次にステップＳ９に進み、ステップＳ８で
確保したＩＢに、ステップＳ７で確保した割当ブロック
の個数と、そのうちの開始割当ブロックの番号を記録す
る。さらにステップＳ１０に進み、ステップＳ８で確保
した記録媒体１の領域（割当ブロック）に、データを記
録する。次にステップＳ１１に進み、ステップＳ５で確
保したメモリ３上のＩＢに、タイムスタンプとファイル
サイズを記録する。また、ステップＳ１２において、メ
モリ３上の管理クラスタ０乃至７の内容を、記録媒体１
上の管理クラスタ０乃至７と、予備管理クラスタ０乃至
７に書き込む。

【０１１４】このようにしてファイルが記録されると、
以後、ＩＢ番号が、記録したデータのファイル識別子と
される。

【０１１５】次に、データを再生するとき、図６のフロ
ーチャートに示す手順で行なう。

【０１１６】最初にステップＳ３１で、再生するファイ
ルのＩＢ番号を含むインデックスセクタを、記録媒体１
からメモリ３上に読み込む。次にステップＳ３２で、そ
のＩＢより、開始割当ブロック番号と割当ブロックの個
数を得る。そして、ステップＳ３３で、記録媒体１上の
その開始割当ブロックから所定の個数の割当ブロックの
データを再生する。

【０１１７】また、データを消去するとき、図７のフロ
ーチャートに示す手順で行なう。

【０１１８】最初にステップＳ５１で、記録媒体１上の
管理クラスタ０乃至７を、メモリ３上に読み込む。次に
ステップＳ５２で、消去するファイルのＩＢを得、開始
割当ブロック番号と割当ブロックの個数を得る。そし
て、ステップＳ５３で、メモリ３上のアロケーションマ
ップにおいて、その割当ブロックに相当するビット列を
０（使用可能）にし、領域を解放する。

【０１１９】さらに、ステップＳ５４で、ＩＢのグルー
プタグに＄ＦＦＦＦを書き、空きＩＢとし、ステップＳ
５５で、メモリ３上の管理クラスタ０乃至７の内容を、
記録媒体１上の管理クラスタ０乃至７と、予備管理クラ
スタ０乃至７に書き込む。

【０１２０】以上のようにして、インデックスセクタ０
乃至２５０により作成されたインデックステーブルの例
を、図８に示す。図８では、以下の説明に関係しない要
素について、−で表し、記述を省略している。

【０１２１】図８に示すように、ＩＢ番号０のファイル
は、グループ０（グループタグ＝０）に属し、６５５３
６（６４ｋ）バイトのデータよりなる。このデータは、
割当ブロック０乃至７の８個の割当ブロックに記録され
ている。

【０１２２】ＩＢ番号１のファイルは、グループ０に属
し、１３１０７２（１２８ｋ）バイトのデータよりな
る。このデータは、割当ブロック８乃至２３の１６個の
割当ブロックに記録されている。

【０１２３】ＩＢ番号２のファイルは、グループ１に属
し、８１９２（８ｋ）バイトのデータよりなる。このデ
ータは、割当ブロック２４の１個の割当ブロックに記録
されている。

【０１２４】ＩＢ番号３のファイルは、グループ２に属
し、１３１０７２（１２８ｋ）バイトのデータよりな
る。このデータは、割当ブロック２５乃至４０の１６個
の割当ブロックに記録されている。

【０１２５】ＩＢ番号４のファイルは、グループ１に属
し、１０４８５７６（１０２４ｋ）バイトのデータより
なる。このデータは、割当ブロック４１乃至１６８の１
２８個の割当ブロックに記録されている。

【０１２６】ＩＢ番号５のファイルは、グループ１に属
し、８１９２（８ｋ）バイトのデータよりなる。このデ
ータは、割当ブロック１６９の１個の割当ブロックに記
録されている。

【０１２７】ＩＢ番号６以降のＩＢは、すべて空きＩＢ
であり、グループタグには、＄ＦＦＦＦが記録されてい
る。

【０１２８】上記グループタグにより、グループ０＝ファイル０（ＩＢ番号０）、ファイル１
（ＩＢ番号１）グループ１＝ファイル２（ＩＢ番号２）、ファイル４
（ＩＢ番号４）、ファイル５（ＩＢ番号５）グループ２＝ファイル３（ＩＢ番号３）のように、各ファイルをグループに分類して記録するこ
とが実現できる。

【０１２９】次に、図９に、上記グループタグをインデ
ックスタグに代え、インデックスタグに他のＩＢ番号を
記録して、階層的管理を行うようにしたインデックステ
ーブルの例を示す。

【０１３０】図９に示すように、ＩＢ０には、インデッ
クスタグに０（自分自身）が記録されており、ルートデ
ィレクトリであることが表されている。また、ファイル
属性には１が記録されており、ディレクトリ属性である
ことが表されている。また、ファイルサイズには０が記
録されており、ファイルの実体データがないことが表さ
れている。

【０１３１】ＩＢ１には、インデックスタグに０が記録
されており、ＩＢ０を親ディレクトリとするファイルで
あることが表されている。また、ファイル属性には０が
記録されており、データ属性のファイルであることが表
されている。また、ファイルサイズは１３１０７２バイ
トとされ、また、そのデータが割当ブロック０から、１
６個の割当ブロックにわたって記録されていることがわ
かる。

【０１３２】ＩＢ３には、インデックスタグに０、ファ
イル属性に１が記録されており、ＩＢ０を親ディレクト
リとするサブディレクトリファイルであることが表され
ている。また、ファイルサイズには０が記録されてお
り、ファイルの実体データがないことが表されている。

【０１３３】ＩＢ４には、インデックスタグに３、ファ
イル属性に０が記録されており、ＩＢ３を親ディレクト
リとするデータファイルであることが表されている。ま
た、ファイルサイズは８１９２バイトであり、そのデー
タが割当ブロック２４に記録されていることがわかる。

【０１３４】ＩＢ番号６以降のＩＢは、すべて空きＩＢ
であり、インデックスタグには＄ＦＦＦＦが記録されて
いる。

【０１３５】このように、インデックスタグに親ディレ
クトリを記述することにより、図１０に示すように、フ
ァイル（ＩＢ）を階層構造で管理することができる。こ
のように、親ディレクトリを記述しておくと、そのファ
イルを作成したとき、親ディレクトリの更新が不要とな
る。

【０１３６】尚、図９の例では、ディレクトリファイル
のサイズを０としたが、ディレクトリファイルはデータ
を持ってもよく、これを利用して、複数キーワードを許
すデータベースを記録するなど、従来のファイルシステ
ムにはない高度な管理構造を実現することもできる。

【０１３７】〈実施例２〉上記実施例１におけるＩＢの
構成は、各ＩＢについて、１つのエクステント記述子し
か記録できない。然るに、一般のデータ記録再生装置に
おいて、可変長データの記録、消去、追記などを繰り返
すと、１つのファイルが複数の記録領域（割当ブロッ
ク）により構成される可能性がある。

【０１３８】そこで、実施例１のアロケーションマップ
による領域管理に代えて、上述したＭＳ−ＤＯＳの場合
と同様に、ＦＡＴによる領域管理を採用し、エクステン
ト記述子として、開始割当ブロック番号を記録すること
が考えられる。

【０１３９】しかしながら、そのようにすると、実施例
１におけるアロケーションマップのサイズが、４セクタ
＝８１９２バイトであったのに対し、同等のＦＡＴを構
成するには、１３１０７０バイト必要であり、必要メモ
リ量が大きくなってしまう。

【０１４０】そこで、さらに別の解決法として、上述し
たＵＮＩＸの例にならい、間接ブロックを用いて複数の
エクステント記述子を記録することが考えられる。

【０１４１】しかしながら、そのようにすると、例え
ば、新たに得たエクステント記述子が１個（４バイト）
であったとしても、１つの割当ブロック＝８１９２バイ
トを消費するため、容量効率が悪くなり、またエクステ
ント記述子がデータ記録領域に散在する可能性が高いた
め、シーク動作の遅いディスク装置等では速度低下の問
題がある。

【０１４２】このようなことから、実施例２において
は、実施例１におけるＩＢに、以下の拡張を施す。

【０１４３】図１１は、ＩＢの基本型を表す。第１の要
素は拡張フラグであり、１ビットで構成される。拡張フ
ラグが１であることにより、基本型のＩＢであることを
示し、０であることにより、拡張型のＩＢ（図１２）で
あることを示す。

【０１４４】第２の要素はインデックスタグであり、１
５ビットで構成される。第３の要素は属性コードであ
り、１６ビットで構成される。第４の要素は更新日時の
タイムスタンプであり、４バイトで構成される。第５の
要素はファイルサイズであり、４バイトで構成される。

【０１４５】第６の要素はリンクフラグであり、１ビッ
トで構成される。リンクフラグが０のとき、第７の要素
はエクステント記述子であり、３１ビットで構成され
る。リンクフラグが１のとき、第７の要素はリンクタグ
であり、１５ビットで構成され、余白の１６ビットは保
留として０を記録する。

【０１４６】図１２は、ＩＢの拡張型を表す。第１の要
素は拡張フラグであり、１ビットで構成される。拡張フ
ラグが０であることにより、拡張型のＩＢであることを
示す。第２の要素はエクステント記述子であり、３１ビ
ットで構成される。

【０１４７】第３の要素は保留ビットであり、０が記録
される。第４の要素はエクステント記述子であり、３１
ビットで構成される。

【０１４８】第５の要素は保留ビットであり、０が記録
される。第６の要素はエクステント記述子であり、３１
ビットで構成される。

【０１４９】第７の要素はリンクフラグであり、１ビッ
トで構成される。リンクフラグが０のとき、第８の要素
はエクステント記述子であり、３１ビットで構成され
る。リンクフラグが１のとき、第８の要素はリンクタグ
であり、１５ビットで構成され、余白の１６ビットは保
留として０を記録する。

【０１５０】図１３は、エクステント記述子の構成例を
示す。１５ビットで示される割当ブロック数により、フ
ァイルデータが記録された領域の大きさを示し、１６ビ
ットの開始割当ブロック番号により、ファイルデータの
記録開始位置を示す。

【０１５１】この図１３に示したＩＢの構成により、Ｉ
Ｂを拡張した例を、図１４に示す。この図は、ファイル
識別子（ＩＢ）＝４として記録されたファイルの例を表
している。

【０１５２】ＩＢ４の拡張フラグは１であり、ＩＢ４が
基本型ＩＢであることを表している。インデックスタグ
は３であり、ＩＢ＝３のディレクトリを親とするファイ
ルであることを表す。ファイル属性は０であり、データ
ファイルであることを表す。

【０１５３】ファイルサイズは５８１６３２であり、５
６８ｋバイト＝７１割当ブロックのサイズであることを
表す。リンクフラグは１であり、他のＩＢに拡張された
ことを表す。リンクタグは６であり、拡張された次のＩ
Ｂは、ＩＢ６であることを表す。

【０１５４】拡張された、ＩＢ６の拡張フラグは０であ
り、ＩＢ６が拡張型ＩＢであることを表している。第１
のエクステント記述子は、割当ブロック８０から、８ブ
ロックにわたってファイルデータが記録されていること
を表す。第２のエクステント記述子は、割当ブロック１
０４から、１６ブロックにわたってファイルデータが記
録されていることを表す。第３のエクステント記述子
は、割当ブロック１７６から、８ブロックにわたってフ
ァイルデータが記録されていることを表す。リンクフラ
グは１であり、ＩＢ４が、ＩＢ６からさらに他のＩＢに
拡張されたことを表す。リンクタグは１３であり、拡張
された次のＩＢは、ＩＢ１３であることを表す。

【０１５５】拡張された、ＩＢ１３の拡張フラグは０で
あり、ＩＢ１３が拡張型ＩＢであることを表している。
第１のエクステント記述子は、割当ブロック２１６か
ら、２４ブロックにわたってファイルデータが記録され
ていることを表す。第２のエクステント記述子は、割当
ブロック２４８から、１５ブロックにわたってファイル
データが記録されていることを表す。リンクフラグは０
であり、ファイル４は、このＩＢで終結することを表
す。

【０１５６】以上説明したように、拡張フラグ、リンク
フラグおよびリンクタグを用いれば、空きＩＢがあるか
ぎり、ファイルにおけるエクステント記述子の個数を自
由に拡張することができる。

【０１５７】〈実施例３〉ところで、実施例１におい
て、データの記録、再生、消去の動作を行うには、上述
したように、クラスタ０，２，４，６，８，１０，１
２，１４の内容（管理クラスタ０乃至７の内容）をメモ
リ３上に持つ必要があり、５１２ｋバイトもの大量のメ
モリを消費することになる。

【０１５８】この問題を解決するため、実施例３におい
ては、以下のようにして、図１５に示すようなＩＢキャ
ッシュシステムを設ける。

【０１５９】（１）記録媒体１上のインデックステーブ
ルを、１２８個のＩＢよりなるインデックスページによ
り構成する。即ち、１管理セクタをもって１インデック
スページとし、２５１インデックスページによりインデ
ックステーブルを構成する（図２）。

【０１６０】（２）メモリ３上に、各インデックスペー
ジにつき１バイトのページアカウントよりなる、２５１
バイトで構成されるページアカウントテーブルを設け
る。各ページアカウントには、そのインデックスページ
中の、空きＩＢの個数が記録される。ページアカウント
テーブルの内容は、記録媒体１上において、ボリューム
情報の１つとして、管理セクタ０に記録される（図
２）。

【０１６１】（３）メモリ３上に、それぞれインデック
スページ１個分を保持できる、４個のページバッファメ
モリを設ける。

【０１６２】（４）メモリ３上に、インデックスページ
番号、ページバッファメモリを指すポインタ、およびペ
ージバッファメモリの内容が更新されたことを示す更新
フラグにより、ページタグを構成し、ページタグ４個に
より、ページタグテーブルを構成する。

【０１６３】（５）メモリ３上に、６５５３６バイト
（１クラスタサイズ）よりなる書き込みバッファを設け
る。

【０１６４】図１６は、ページタグテーブルの構成例を
示す。ページタグテーブルは、０乃至３の４つのページ
タグで構成され、各ページタグは、１バイトよりなる更
新フラグ（この更新フラグは、記録媒体１からメモリ３
（ページバッファメモリ）に読み出したデータが、メモ
リ３上において更新されたとき、１とされ、更新されな
いとき（記録媒体１のデータと同一のデータであると
き）、０とされる）と、１バイトよりなるインデックス
ページ番号と、４バイトよりなるページバッファポイン
タで構成される。

【０１６５】上記構成において、記録媒体１上のインデ
ックスページＮの内容を、メモリ３上のページバッファ
メモリに読み出すには、図１７のフローチャートに示す
手順で行なう。

【０１６６】最初にステップＳ９１で、変数ｉに０を初
期設定した後、ステップＳ９２で、ページタグ０のイン
デックスページ番号を読み出し、ステップＳ９３で、そ
の値を判定する。その値がＮと判定されたとき、インデ
ックスページＮがページバッファメモリ０に既に読み込
まれているので、処理を終了する。インデックスページ
番号がＮでないとき、ステップＳ９４で、＄ＦＦ（未使
用）か否かを判定し、ＹＥＳならば、ステップＳ９５に
進み、ページタグ０のインデックスページ番号にＮを書
き込み、そのページバッファポインタの指すページバッ
ファメモリに、記録媒体１上のインデックスページＮを
読み出し、処理を終了する。

【０１６７】ステップＳ９４で、インデックスページ番
号が＄ＦＦではない（使用済）と判定されたとき、ステ
ップＳ９６で、変数ｉを判定し、変数ｉが３でないと判
定されれば、ステップＳ９７で、変数ｉを１だけインク
リメントし（ｉ＝１とし）、ステップＳ９８で、ページ
タグ０とページタグｉ（いまの場合、ｉ＝１）を交換す
る。

【０１６８】そして、ステップＳ９２に戻り、交換した
ページタグ０のインデックスページ番号を読み出し、ス
テップＳ９３でＮと判定されたら終了する。番号がＮで
なければ、ステップＳ９４で＄ＦＦ（未使用）か否かを
判定し、ページタグ０のインデックスページ番号が＄Ｆ
Ｆ（未使用）ならば、ステップＳ９５に進み、そのイン
デックスページ番号にＮを書き込み、そのページバッフ
ァポインタの指すページバッファに、記録媒体１上のイ
ンデックスページＮを読み出し、処理を終了する。

【０１６９】インデックスページ番号が＄ＦＦでないと
き（使用済のとき）、ステップＳ９６で、ｉ＝３でなけ
れば（いまの場合、ｉ＝１）、ステップＳ９７で、ｉを
１だけインクリメントして、ｉ＝２とした後、ステップ
Ｓ９８で、ページタグ０とページタグｉ（いまの場合、
ｉ＝２）を交換する。

【０１７０】再びステップＳ９２に戻り、交換したペー
ジタグ０のインデックスページ番号を読み出し、Ｎなら
ば、処理を終了する。また、ステップＳ９４で、ページ
タグ０のインデックスページ番号が＄ＦＦ（未使用）と
判定されたならば、ステップＳ９５で、そのインデック
スページ番号にＮを書き込み、そのページバッファポイ
ンタの指すページバッファメモリに、記録媒体１上のイ
ンデックスページＮを読み出し、処理を終了する。

【０１７１】さらに、インデックスページ番号が＄ＦＦ
ではなく（使用済であり）、ｉが３でなければ（いまの
場合、ｉ＝２）、ｉを１だけインクリメントして、ｉ＝
３とし、ページタグ０とページタグｉ（いまの場合、ｉ
＝３）を交換する。

【０１７２】ステップＳ９２で、再び読み取ったページ
タグ０のインデックスページ番号がＮならば、処理を終
了する。そのページタグ０のインデックスページ番号が
＄ＦＦ（未使用）ならば、ステップＳ９５で、そのイン
デックスページ番号にＮを書き込み、そのページバッフ
ァポインタの指すページバッファメモリに、記録媒体１
上のインデックスページＮを読み出し、処理を終了す
る。

【０１７３】ステップＳ９４とステップＳ９６で、イン
デックスページ番号が＄ＦＦではなく（使用済であ
り）、かつ、ｉ＝３と判定されたとき、結局、ページバ
ッファ０乃至３の４個が全て使用済であることになる。
この場合、ステップＳ９９に進み、ページタグ０の更新
フラグが１（対応するページバッファメモリのデータを
更新した）か否か判定し、１ならば、ステップＳ１００
に進み、ページタグ０のページバッファポインタの指す
ページバッファメモリのデータ（更新データ）を、その
インデックスページ番号の示すインデックスページ（記
録媒体１）に書き込み、その更新フラグを０にする。即
ち、更新データを保存する。

【０１７４】次にステップＳ１０１に進み、ページタグ
０のインデックスページ番号にＮを書き込み、そのペー
ジバッファポインタの指すページバッファメモリに、記
録媒体１上のインデックスページＮの内容を読み出し、
処理を終了する。

【０１７５】ステップＳ９９で、更新フラグが０（デー
タを更新していない）と判定されたとき、保存処理は不
要となるので、ステップＳ１００の処理はスキップさ
れ、ステップＳ１０１の処理が直ちに実行される。

【０１７６】この手順による具体例として、図１８およ
び図１９を参照し、ページタグテーブルの動作につい
て、さらに説明する。

【０１７７】図１８（ａ）は、ページタグテーブルの初
期状態を示す。メモリ３上には、４つのページバッファ
メモリが、それぞれアドレス＄１００００，＄１０８０
０，＄１１０００，＄１１８００に置かれており、各ペ
ージタグのページバッファポインタは、この各アドレス
を指している。また、各インデックスページ番号は、＄
ＦＦであり、未使用ページタグであることを示す。

【０１７８】図１８（ｂ）は、インデックスページ０を
読み出した状態を表している。ページタグ０のインデッ
クスページ番号には０が書かれ、メモリ３上のアドレス
＄１００００（ページバッファメモリ０）に、記録媒体
１からインデックスページ０の内容が読み込まれる。

【０１７９】図１８（ｃ）は、さらに、インデックスペ
ージ１を読み出した状態を表している。ページタグ０と
ページタグ１が交換され、ページタグ０のインデックス
ページ番号には１が書かれ、メモリ３上のアドレス＄１
０８００（ページバッファメモリ１）に、インデックス
ページ１の内容が読み込まれる。

【０１８０】図１８（ｄ）は、同様にして、インデック
スページ２および３を読み出した状態を表している。同
図に示すように、若いページタグには、より新しいイン
デックスページが順次記録される。

【０１８１】図１９（ａ）は、ページタグ３と１の更新
フラグが１であり、インデックスページ０と２の内容が
更新された状態を表している。

【０１８２】図１９（ｂ）は、インデックスページ４を
読み込む途中（図１８（ｃ）に至るまでの途中）経過を
表している。最も古いページタグ３（図１８（ａ））を
ページタグ０に移し、そのインデックスページ０の内容
（更新されている）を記録媒体１に書き込んで、更新フ
ラグをクリアする。このとき、後の書き込み動作を節約
するため、同一クラスタに属するインデックスページ２
も、同時に書き込み、更新フラグをクリアする。

【０１８３】図１９（ｃ）は、インデックスページ４を
読み込んだ状態を表している。ページタグ０のインデッ
クスページ番号には４が書かれ、メモリ３のアドレス＄
１００００に、インデックスページ４の内容が読み込ま
れる。

【０１８４】図１９（ｄ）は、再びインデックスページ
２を読み出した状態を表している。既にページバッファ
メモリに読み出されているため、実際の読み出し動作は
行なわれず、最新にアクセスされたページとして、ペー
ジタグ２がページタグ０に移されるだけであり、高速に
動作する。

【０１８５】図１７のステップＳ１００において、ペー
ジタグ０のページバッファポインタが指すページバッフ
ァメモリのデータを、そのインデックスページ番号の示
すインデックスページ（記録媒体１）に書き込むとき、
図２０のフローチャートに示す手順で行なう。

【０１８６】最初にステップＳ１２１で、ページタグ０
のインデックスページ番号（０乃至２５０）から、クラ
スタ番号Ｃ０とセクタ番号Ｓ０を求める。即ち、この実
施例の場合、１インデックスページを１セクタとしてい
るため、インデックスページ番号は、インデックスセク
タ番号（０乃至２５０）と等しい。このインデックスペ
ージ番号をＮとすると、ボリューム情報セクタとビット
マップセクタ０乃至３の合計５セクタを加味して、クラ
スタ番号Ｃ０は、（Ｎ＋５）÷３２の商を、２倍して
（予備管理クラスタのため）得られる。また。（Ｎ＋
５）÷３２の余りが、セクタ番号Ｓ０となる。

【０１８７】例えば、インデックスページ２７は、（２
７＋５）÷３２＝１（余り０）であり、クラスタ番号＝
２、セクタ番号＝０となる。

【０１８８】次にステップＳ１２２で、記録媒体１上の
クラスタＣ０のデータを、メモリ３上の書き込みバッフ
ァメモリ（１クラスタサイズ）に読み込む。そしてステ
ップＳ１２３で、書き込みバッファ中のＳ０×２０４８
バイトの位置へ、ページタグ０のページバッファポイン
タが指すページバッファメモリの内容（１セクタ分）を
コピーする（図１７における場合と同様の処理が行われ
る）。

【０１８９】次にステップＳ１２４で、変数ｉを１に初
期設定し、ステップＳ１２５で、ページタグｉ（いまの
場合、ｉ＝１）のインデックスページ番号から、上述し
た場合と同様にして、クラスタ番号Ｃ１とセクタ番号Ｓ
１を求める。さらにステップＳ１２６で、クラスタ番号
Ｃｉ（いまの場合、Ｃｉ＝Ｃ１）がクラスタ番号Ｃ０と
等しいか否か、即ち、同一クラスタＣ０に含まれるか否
かを判定し、Ｃｉ＝Ｃ０（同一クラスタ）ならば、ステ
ップＳ１２７に進み、書き込みバッファメモリ中のＳｉ
×２０４８（いまの場合、Ｓｉ＝Ｓ１）バイトの位置
へ、ページタグｉ（いまの場合、ｉ＝１）のページバッ
ファポインタが指すページバッファメモリの内容をコピ
ーする。

【０１９０】Ｃｉ＝Ｃ０ではない場合（異なるクラスタ
の場合）、またはステップＳ１２７のコピーが完了した
とき、ステップＳ１２８に進み、変数ｉが３でなけれ
ば、さらにステップＳ１２９に進み、変数ｉを１だけイ
ンクリメントして、ｉ＝２とする。

【０１９１】そして、再びステップＳ１２５に戻り、ペ
ージタグｉ（ｉ＝２）のインデックスページ番号から、
クラスタ番号Ｃｉ（＝Ｃ２）と、セクタ番号Ｓｉ（＝Ｓ
２）を求める。

【０１９２】そして、Ｃ２＝Ｃ０ならば、書き込みバッ
ファ中のＳ２×２０４８バイトの位置へ、ページタグ２
のページバッファポインタが指すページバッファメモリ
の内容をコピーする。

【０１９３】同様に、ｉをインクリメントして、ｉ＝３
とし、ページタグ３のインデックスページ番号から、ク
ラスタ番号Ｃ３とセクタ番号Ｓ３を求める。そして、Ｃ
３＝Ｃ０ならば、書き込みバッファ中のＳ３×２０４８
バイトの位置へ、ページタグ３のページバッファポイン
タが指すページバッファメモリの内容をコピーする。

【０１９４】ステップＳ１２８において、ｉ＝３と判定
されたとき（ページバッファ０乃至３の全ての内容が書
き込みバッファメモリに書き込まれたとき）、ステップ
Ｓ１３０に進み、書き込みバッファメモリのデータを、
記録媒体１上のクラスタＣ０に記録する。

【０１９５】このようにして、図１５に示すように、記
録媒体１から書き込みバッファメモリに１クラスタ分の
データが読み込まれ、ページタグの指すページバッファ
メモリのデータが書き込みバッファメモリの所定のセク
タ位置に移され、書き込みバッファメモリの内容が記録
媒体１の元のクラスタに書き込まれる。

【０１９６】ところで、上記構成のＩＢキャッシュシス
テムにおいて、空きＩＢを見つけるために、インデック
スページを０から順にメモリ３上に読み出して調べるよ
うにすると、速度低下の原因となる。これをさけるた
め、この実施例においては、各インデックスページにお
ける空きＩＢの個数を記録するページアカウントテーブ
ルが、記録媒体１のボリューム情報セクタ内に設けられ
ている。

【０１９７】図２１は、ページアカウントテーブルの例
である。同図に示すように、インデックスページ０のペ
ージアカウントは０であり、空きＩＢがないことを表し
ている。また、インデックスページ１のページアカウン
トは１であり、空きＩＢが１個あることを表している。
また、インデックスページ２のページアカウントは７１
であり、空きＩＢが７１個あることを表している。さら
に、インデックスページ２５０のページアカウントは１
２８であり、全てのＩＢが空きであることを表してい
る。

【０１９８】基本型ＩＢ（図１１）を記録するために空
きＩＢを求める場合は、ページアカウントが２以上のイ
ンデックスページを読み込む。なぜなら、基本型ＩＢは
エクステント記述子が１個しか記録できないため、すぐ
に次の空きＩＢが必要になる可能性が高いが、この場
合、そのＩＢが同一ページ（同一のインデックスセク
タ）にあれば、高速化が期待できるからである。

【０１９９】また、拡張型ＩＢ（図１２）を記録するた
めに空きＩＢを求める場合は、１つ前の拡張型ＩＢまた
は基本型ＩＢが属するインデックスページのページアカ
ウントから昇順に走査する。なぜなら、それより前に空
きＩＢがあったとしても、それは他のファイルが消去さ
れた結果であるため、ランダムな位置にあり、距離が遠
くなって、ＩＢキャッシュの効果が減少するからであ
る。

【０２００】以上のＩＢキャッシュシステムにおいて、
データを記録するには、図２２と図２３のフローチャー
トに示す手順で行う。

【０２０１】最初にステップＳ１５１で、記録媒体１上
のページアカウントテーブル（図２１）を走査し、ステ
ップＳ１５２で、ページアカウントが２以上のインデッ
クスページＮが見つかったか否かを判定し、見つからな
ければ、エラーとして処理を終了する。見つかったとき
は、ステップＳ１５３に進み、記録媒体１上のインデッ
クスページＮのデータ（１セクタ分のデータ）を、ペー
ジタグ０のポインタが指定するページバッファメモリに
読み込む。

【０２０２】次にステップＳ１５４で、そのページバッ
ファメモリを走査して空きＩＢ（インデックスタグ＝＄
ＦＦＦＦのＩＢ）を得、そのインデックスタグに、例え
ば、その上位のＩＢ番号を記録するとともに、属性コー
ドに、ディレクトリ属性なら１、データ属性なら０を記
録して、ＩＢを確保し、ページタグ０の更新フラグを１
（更新）にする。また、そのページアカウントを１減ら
す。さらにステップＳ１５５で、記録媒体１上のアロケ
ーションマップを走査し、必要な個数の連続する空き
（ビットが０の）割当ブロックを見つけ、対応するアロ
ケーションマップのビットを１（使用済）にして、その
割当ブロックを確保する。

【０２０３】ステップＳ１５６では、ステップＳ１５４
で確保したＩＢに、エクステント記述子として、ステッ
プＳ１５５で確保した開始割当ブロック番号と割当ブロ
ックの個数を記録する。ステップＳ１５７では、ステッ
プＳ１５５で確保した領域（割当ブロック）に、データ
を記録する（図２０に示した場合と同様の処理が行われ
る）。また、ステップＳ１５８で、メモリ３のＩＢに、
タイムスタンプとファイルサイズを記録する。このメモ
リ３上のＩＢは、メモリ３上のその記憶領域を他の目的
のために使用するとき、装置の電源をオフするとき、記
録媒体１をイジェクトするときなど、所定のタイミング
で、さらに記録媒体１に記録される。

【０２０４】尚、以後、このＩＢ番号を、記録したデー
タのファイル識別子とする。

【０２０５】ＩＢキャッシュシステムにおいて、データ
を再生するには、図２４と図２５のフローチャートに示
す手順で行う。

【０２０６】最初にステップＳ１７１で、再生するファ
イルのＩＢ番号を１２８（ページバッファメモリに記憶
される１ページ分のインデックスページのＩＢの個数）
で割り、その商の整数部から、インデックスページ番号
を得る。ステップＳ１７２では、そのインデックスペー
ジのデータを、ページバッファに読み込む（図１７に示
した場合と同様の処理が行われる）。そしてステップＳ
１７３では、ページバッファメモリ中のそのＩＢから、
ファイルサイズを得る。

【０２０７】次にステップＳ１７４において、ファイル
サイズを判定し、０ならば、終了する。

【０２０８】次にステップＳ１７５において、リンクフ
ラグを判定し、リンクフラグが０なら、ステップＳ１７
６に進み、そのエクステント記述子から開始割当ブロッ
クを得、ステップＳ１７７において、その開始割当ブロ
ックから上記したファイルサイズのデータを再生し、終
了する。ステップＳ１７５において、リンクフラグが１
なら、ステップＳ１７８に進む。

【０２０９】ステップＳ１７８において、リンクタグよ
り次の拡張ＩＢ番号を得る。

【０２１０】次にステップＳ１７９で、拡張ＩＢ番号を
１２８で割り、その商の整数部から、インデックスペー
ジ番号を得る。そしてステップＳ１８０で、そのインデ
ックスページのデータを、ページバッファに読み込む
（図１７に示した場合と同様の処理が行われる）。

【０２１１】次にステップＳ１８１で、変数ｉに０を初
期設定する。

【０２１２】次にステップＳ１８２において、第ｉ（い
まの場合、第０）のエクステント記述子から、割当ブロ
ック数と開始割当ブロック番号を得る。

【０２１３】次にステップＳ１８３において、ファイル
サイズとエクステントサイズ、即ち、割当ブロック数×
割当ブロックサイズを比較し、エクステントサイズの方
が大きいか等しければ、ステップＳ１８５に進み、開始
割当ブロックから上記ファイルサイズのデータを再生
し、終了する。

【０２１４】ステップＳ１８３において、ファイルサイ
ズの方が大きければ、ステップＳ１８４に進み、開始割
当ブロックから上記エクステントサイズのデータを再生
する。

【０２１５】次にステップＳ１８６において、ファイル
サイズから上記エクステントサイズ、即ち、割当ブロッ
ク数×割当ブロックサイズを減じ、また変数ｉをインク
リメントして、ｉ＝１とする。そしてステップＳ１８７
で、ｉ＝４でないことを確認し、次にステップＳ１８８
で第ｉ（いまの場合、第１）のエクステント記述子の最
上位ビット（リンクフラグ）を判定し、リンクフラグが
０ならば、ステップＳ１８２に戻って、次のエクステン
トを再生し、リンクフラグが１ならば、ステップＳ１７
８に戻って、次の拡張ＩＢを得る。

【０２１６】ステップＳ１８７において、ｉ＝４のと
き、ファイルサイズが０でないのに次の拡張ＩＢがない
ことを意味するので、エラーであり、エラー処理を行
う。

【０２１７】さらに、ＩＢキャッシュシステムにおい
て、データを消去するには、図２６乃至図２８のフロー
チャートに示す手順で行う。

【０２１８】最初にステップＳ２０１で、消去するファ
イルのＩＢ番号を１２８で割り、その商の整数部から、
インデックスページ番号を得る。そしてステップＳ２０
２において、そのインデックスページのデータを、ペー
ジバッファに読み込む（図１７に示した場合と同様の処
理を行う）。次にステップＳ２０３で、ページバッファ
メモリ中のそのＩＢから、ファイルサイズを得、ステッ
プＳ２０４で、そのファイルサイズを判定し、０なら
ば、ステップＳ２０５以降のデータ領域の解放処理をス
キップし、ステップＳ２０８に進む。

【０２１９】ファイルサイズが０でなければ、ステップ
Ｓ２０５において、リンクフラグを判定し、リンクフラ
グが０なら、ステップＳ２０６で、そのエクステント記
述子から割当ブロック数と開始割当ブロック番号を得、
次にステップＳ２０７で、アロケーションマップにおい
て、上記開始割当ブロック番号のビット位置から、割当
ブロック数分のビットを０にして、データ領域を解放す
る。

【０２２０】次にステップＳ２０８において、そのＩＢ
のインデックスタグに＄ＦＦＦＦを記録して未使用ＩＢ
とし、ステップＳ２０９において、そのＩＢが属するペ
ージバッファを指すページタグの更新フラグをセット
し、ステップＳ２１０において、そのインデックスペー
ジのページアカウントをインクリメントし、終了する。

【０２２１】ステップＳ２０５において、リンクフラグ
が１（次のＩＢがある）なら、ステップＳ２１１に進
み、そのリンクタグより次の拡張ＩＢ番号を得、次にス
テップＳ２１２で、いまのＩＢのインデックスタグに＄
ＦＦＦＦを記録して未使用ＩＢとし、ステップＳ２１３
において、そのＩＢが属するページバッファを指すペー
ジタグの更新フラグをセットし、ステップＳ２１４にお
いて、そのインデックスページのページアカウントをイ
ンクリメントする。

【０２２２】次にステップＳ２１５において、拡張ＩＢ
番号を１２８で割り、インデックスページ番号を得る。
そしてステップＳ２１６で、そのインデックスページの
データを、ページバッファに読み込み（図１７に示した
場合と同様の処理を行う）、次にステップＳ２１７で、
変数ｉを０で初期化する。

【０２２３】次にステップＳ２１８で、第ｉ（いまの場
合、第０）のエクステント記述子を得て、割当ブロック
数と開始割当ブロック番号を得る。次にステップＳ２１
９で、アロケーションマップにおいて、上記開始割当ブ
ロック番号のビット位置から、割当ブロック数分のビッ
トを０にして、データ領域を解放する。

【０２２４】次にステップＳ２２０において、ファイル
サイズからエクステントサイズ、即ち、割当ブロック数
×割当ブロックサイズを引くとともに、変数ｉをインク
リメントする。

【０２２５】次にステップＳ２２１において、ファイル
サイズを判定し、０または負ならば、ステップＳ２２４
で、そのＩＢのインデックスタグに＄ＦＦＦＦを記録し
て未使用ＩＢとし、ステップＳ２２５において、そのＩ
Ｂが属するページバッファを指すページタグの更新フラ
グをセットし、ステップＳ２２６において、そのインデ
ックスページのページアカウントをインクリメントし、
終了する。

【０２２６】ステップＳ２２１で、ファイルサイズが正
ならば、ステップＳ２２２で、ｉ＝４でないことを確認
し、次にステップＳ２２３で第ｉ（いまの場合、第１）
のエクステント記述子の最上位ビット（リンクフラグ）
を判定し、リンクフラグが０ならば、ステップＳ２１８
に戻って、次のエクステントを解放し、リンクフラグが
１ならば、ステップＳ２１１に戻って、次の拡張ＩＢを
得る。

【０２２７】ステップＳ２２２において、ｉ＝４のと
き、ファイルサイズが正であるのに次の拡張ＩＢがない
ことを意味するので、エラーであり、エラー処理を行
う。

【０２２８】〈実施例４〉実施例１の説明におけるイン
デックスタグの説明（図９）において、ディレクトリ属
性のＩＢのファイルサイズを０としたが、ディレクトリ
ファイルに実体のデータを持たせることもできる。この
ようにした場合、より高度なファイル管理方法を実現す
ることができる。図２９は、その実施例を表している。

【０２２９】即ち、この実施例においては、ＩＢ＝３、
ＩＢ＝４、ＩＢ＝５が、いずれも、最初の拡張フラグが
１とされ、基本型ＩＢとされている。ＩＢ＝３のインデ
ックスタグは０とされ、ルートディレクトリ直下のファ
イルであることが示されている。また、属性コードは１
とされ、ディレクトリ属性のファイルとされている。フ
ァイルサイズは４バイトとされ、割当ブロック２４か
ら、１割当ブロックの領域が割り当てられている。ＩＢ
＝４のインデックスタグは３とされ、ＩＢ＝３のディレ
クトリ直下のファイルとされている。また、属性コード
は０とされ、データ属性のファイルとされている。さら
に、ファイルサイズは２１２バイトとされ、割当ブロッ
ク２５から、１割当ブロックの領域が割り当てられてい
る。ＩＢ＝５のインデックスタグは３とされ、ＩＢ＝３
のディレクトリ直下のファイルとされている。また、属
性コードは０とされ、データ属性のファイルとされてい
る。さらに、ファイルサイズは１８０バイトとされ、割
当ブロック２６から、１割当ブロックの領域が割り当て
られている。

【０２３０】図２９に示すように、この実施例の場合、
ＩＢ＝３の割当ブロック２４は、各２バイトからなるＩ
Ｂ番号のリストで構成され、そこに子ファイルのＩＢ番
号が記録される。即ち、この実施例では、ＩＢ＝４とＩ
Ｂ＝５の２つのＩＢ番号が記録されている。

【０２３１】前述のインデックスタグのみによるファイ
ルの階層的管理方法においては、新しいファイルの記録
や、ＩＢ番号がわかっているファイルの再生は、高速に
行うことが可能であるが、同一のディレクトリに属する
子ファイルを検索する場合、インデックステーブルをす
べて走査する必要があるため、時間がかかることにな
る。しかしながら、この実施例のようにすれば、ディレ
クトリファイルから子ファイルを検索することができ、
子ファイルの検索が高速化される。

【０２３２】〈実施例５〉図３０は、他の実施例を表し
ている。図２９の実施例と異なり、この実施例において
は、ＩＢ＝３のファイルサイズが３２バイトとされ、割
当ブロック２４のエントリは、１６バイトとされ、そこ
にはＩＢ番号（２バイト）だけでなく、ファイル名（１
４バイト）も記録されるようになされている。

【０２３３】図３０の実施例においては、ＩＢ＝３のデ
ィレクトリの下に、割当ブロック２４に、”ＣＯＮＦＩ
Ｇ．ＳＹＳ”および”ＡＵＴＯＥＸＥＣ．ＢＡＴ”とい
う２つのファイルが記録されている。勿論、ＩＢ＝３の
ディレクトリファイル自身にも、ファイル名を付けるこ
とができ、そのファイル名は、ＩＢ＝０のルートディレ
クトリファイルに記録される。

【０２３４】上記の構成により、各ＩＢに登録されたフ
ァイルは、ファイル名を持つことができ、コンピュータ
のＯＳのように、ファイル名を必要とする、従来のファ
イルシステムにも容易に適用することができる。

【０２３５】尚、図３０においては、簡単のため、ディ
レクトリファイルの構成を、ＩＢ番号と固定長のファイ
ル名のみとしたが、次のようにすることも可能である。

【０２３６】（１）ファイル名の長さ、各エントリの長
さを記録し、可変長にする。（２）ファイル名のみならず、記録者名や著作権表示等
を記録したり、ウインドウシステムで使用するアイコン
データを記録するなど、ファイル固有の諸情報を、合わ
せて記録する。（３）ファイル名をキーとして、２分木、Ｂツリー、ハ
ッシュ表等の構成とし、子ファイルが多数の場合のファ
イル名検索を高速化する。（４）各エントリ中に、再生順序の番号を記録するな
ど、子ファイルの順番を管理する手段を設ける。

【０２３７】〈実施例６〉前記実施例４と実施例５の説
明において、属性コードは、０をデータ属性、１をディ
レクトリ属性としたが、属性コードを複数ビットにより
構成し、前記ディレクトリファイルの構成方法を、用途
に応じて複数種類持つようにすることができる。図３１
は、その実施例を表している。

【０２３８】図３１において、ＩＢ＝０のルートディレ
クトリの子ファイルとして、ＩＢ＝１、ＩＢ＝２、ＩＢ
＝３と、３つのＩＢが示されている。

【０２３９】ＩＢ＝１の属性コードは０とされ、データ
属性のファイルとされている。そして、そのデータは、
割当ブロック１０に記録されている。ＩＢ＝２の属性コ
ードは１とされ、第１の種類のディレクトリファイルと
されている。図３１においては、第１の種類のディレク
トリファイルとして、前記実施例４に準じ、ＩＢ＝２で
指定される割当ブロック１１に、子ファイルのＩＢ番号
リストが記録されている。ＩＢ＝３の属性コードは２と
され、第２の種類のディレクトリファイルとされてい
る。この図においては、第２の種類のディレクトリファ
イルとして、前記実施例５に準じ、ＩＢ＝３で指定され
る割当ブロック１２に、子ファイルのＩＢ番号とファイ
ル名のリストが記録されている。

【０２４０】同様にして、用途に応じた多数の種類のデ
ィレクトリファイルを、同一ファイルシステム上に混在
させることができる。このように、ディレクトリファイ
ルの種類が多くなると、応用機器によっては、すべての
種類をサポートできない場合があると思われる。しか
し、前記実施例１において説明したように、ファイルの
階層構造に関する情報は、ＩＢ中のインデックスタグに
も記録されているため、そのような場合においても、フ
ァイルの階層構造を簡単に知ることができる。

【０２４１】尚、本発明はこの実施例にのみ限定される
ものではなく、例えば、次のような変形が可能である。

【０２４２】（１）割当ブロックの管理をアロケーショ
ンマップ（ビットマップ）ではなく、ＦＡＴで行なう。

【０２４３】この場合、エクステント記述子を、割当ブ
ロック数と開始割当ブロック番号ではなく、ＦＡＴの開
始クラスタで表すことができる。

【０２４４】（２）割当ブロックの管理をアロケーショ
ンマップ（ビットマップ）ではなく、例えば、本出願人
が特願平５−１１４８６３号の実施例３として先に提案
したような、空きの割当ブロックの番号を直接記録した
ノードマップまたはノードリストで行なう。

【０２４５】この場合、エクステント記述子を、割当ブ
ロック数と開始割当ブロック番号ではなく、ノード番号
で表すことができる。

【０２４６】（３）ＩＢのサイズを１６バイトではな
く、他のサイズにし、基本型ＩＢにおける要素の一部
（属性コード、タイムスタンプ）を省略するか、または
他の要素（ファイル名、ユーザーＩＤなど）を記録す
る。

【０２４７】

【発明の効果】以上説明したように、本発明によれば、
ファイルの階層的管理に必要な情報を、全てインデック
ス領域に集中したことにより、文字入力手段を持たない
機器においても、従来に比較して、小さなメモリ容量
で、高速なファイルアクセスが実現できる。

【０２４８】また、上記インデックステーブルをページ
単位で管理できる機構にすることにより、より少量のメ
モリでより高速なファイルアクセスが実現できる。

【図面の簡単な説明】

【図１】本発明のファイル管理方法を適用したデータ記
録媒体のフォーマットを説明する図である。

【図２】図１の実施例をさらに具体化したフォーマット
を説明する図である。

【図３】インデックスブロックの構成を説明する図であ
る。

【図４】本発明の実施例１におけるデータ記録処理を説
明するフローチャートである。

【図５】図４に続くフローチャートである。

【図６】実施例１における再生処理を説明するフローチ
ャートである。

【図７】実施例１における消去処理を説明するフローチ
ャートである。

【図８】グループタグによるインデックステーブルを説
明する図である。

【図９】インデックスタグによるインデックステーブル
を説明する図である。

【図１０】インデックスタグによる階層構造を説明する
図である。

【図１１】インデックスブロックの基本型の構成を説明
する図である。

【図１２】インデックスブロックの拡張型の構成を説明
する図である。

【図１３】エクステント記述子の構成を説明する図であ
る。

【図１４】インデックスブロックの拡張を説明する図で
ある。

【図１５】インデックスブロックのキャッシュシステム
を説明する図である。

【図１６】ページタグテーブルを説明する図である。

【図１７】ページバッファへの読み出し処理を説明する
フローチャートである。

【図１８】ページタグテーブルの動作を説明する図であ
る。

【図１９】ページタグテーブルの他の動作を説明する図
である。

【図２０】ページバッファの書き込み処理を説明する図
である。

【図２１】ページアカウントテーブルの具体例を説明す
る図である。

【図２２】インデックスブロックのキャッシュシステム
における記録処理を説明するフローチャートである。

【図２３】図２２に続くフローチャートである。

【図２４】インデックスブロックのキャッシュシステム
における再生処理を説明するフローチャートである。

【図２５】図２４に続くフローチャートである。

【図２６】インデックスブロックのキャッシュシステム
における消去処理を説明するフローチャートである。

【図２７】図２６に続くフローチャートである。

【図２８】図２７に続くフローチャートである。

【図２９】実施例４の構成を説明する図である。

【図３０】実施例５の構成を説明する図である。

【図３１】実施例６の構成を説明する図である。

【図３２】従来のファイル管理方法を適用したデータ記
録再生装置の構成例を示すブロック図である。

【図３３】ＭＳ−ＤＯＳファイルシステムを説明する図
である。

【図３４】ＭＳ−ＤＯＳのルートディレクトリを説明す
る図である。

【図３５】ＭＳ−ＤＯＳの階層的ファイル管理を説明す
る図である。

【図３６】ＭＳ−ＤＯＳにおける記録処理を説明するフ
ローチャートである。

【図３７】ＭＳ−ＤＯＳにおける再生処理を説明するフ
ローチャートである。

【図３８】ＭＳ−ＤＯＳにおける消去処理を説明するフ
ローチャートである。

【図３９】ＵＮＩＸファイルシステムの構成例を示す図
である。

【図４０】ｉノードリストを説明する図である。

【図４１】ＵＮＩＸにおける階層的ファイル管理を説明
する図である。

【図４２】ｉノードにおける記録処理を説明するフロー
チャートである。

【図４３】図４２に続くフローチャートである。

【図４４】ｉノードにおける再生処理を説明するフロー
チャートである。

【図４５】ｉノードにおける消去処理を説明するフロー
チャートである。

【図４６】図４５に続くフローチャートである。

【図４７】ミニディスクの構成を説明する図である。

【図４８】ミニディスクにおけるＵＴＯＣセクタ０を説
明する図である。

【図４９】ミニディスクにおける記録処理を説明するフ
ローチャートである。

【図５０】ミニディスクにおける再生処理を説明するフ
ローチャートである。

【図５１】ミニディスクにおける消去処理を説明するフ
ローチャートである。

【符号の説明】

１データ記録媒体２媒体駆動部３メモリ４ＣＰＵ５データ入力部６データ出力部

Claims

【特許請求の範囲】

【請求項１】多数のブロックに区分した領域にファイ
ルを記録し、再生するようにした記録媒体のファイルを
管理するファイル管理方法において、前記記録媒体に、前記ブロックの使用状態を表す使用情
報を記録するブロック管理領域を形成するとともに、前
記ファイルの記録に使用された前記ブロックに関するイ
ンデックス情報を記録するインデックス領域とを形成
し、前記インデックス領域に、前記ファイルを関連づける関
連情報を記録することを特徴とするファイル管理方法。
【請求項２】前記関連情報は、前記ファイルをグルー
プに分類して管理するグループタグを含むことを特徴と
する請求項１に記載のファイル管理方法。
【請求項３】前記関連情報は、親の前記ファイルを特
定する番号を記録するインデックスタグを含むことを特
徴とする請求項１に記載のファイル管理方法。
【請求項４】前記関連情報は、連続する前記インデッ
クス領域を特定する情報を記録するリンクタグを含むこ
とを特徴とする請求項１または３に記載のファイル管理
方法。
【請求項５】前記関連情報は、前記リンクタグに連続
する前記インデックス領域を特定する情報が記録されて
いるか否かを表すリンクフラグをさらに含むことを特徴
とする請求項４に記載のファイル管理方法。
【請求項６】前記関連情報は、１つの前記ファイルを
管理する複数の前記インデックス領域のうち、先頭のイ
ンデックス領域であるか否かを表す拡張フラグをさらに
含むことを特徴とする請求項１，３または４に記載のフ
ァイル管理方法。
【請求項７】複数の前記インデックス領域に記録され
た情報によりインデックスページを形成し、前記インデックスページの１ページ分の情報を記憶する
ことができるページバッファメモリを複数ページ分設
け、前記ページバッファメモリを管理する情報を記憶するペ
ージタグを形成し、前記ページタグに、前記インデックスページを特定する
番号、前記ページバッファメモリを指定するポインタ、
前記ページバッファメモリの内容が更新されたか否かを
表す更新情報の少なくとも１つを記録することを特徴と
する請求項１，４または５に記載のファイル管理方法。
【請求項８】前記記録媒体に、前記インデックスペー
ジにおける未使用インデックス領域の数を表すページア
カウントを記録するページアカウント領域を形成するこ
とを特徴とする請求項７に記載のファイル管理方法。
【請求項９】前記記録媒体のページアカウント領域よ
り読み出した前記ページアカウントを記憶するページア
カウントテーブルをメモリに形成することを特徴とする
請求項８に記載のファイル管理方法。
【請求項１０】前記インデックス領域には、グループ
タグ、インデックスタグ、属性コード、タイムスタン
プ、ファイルサイズおよびエクステント記述子の少なく
とも１つを有するインデックスブロックを記録すること
を特徴とする請求項１に記載のファイル管理方法。
【請求項１１】前記インデックスブロックは、リンク
された一連の前記インデックスブロックの先頭の前記イ
ンデックスブロックに適用される基本型フォーマット
と、他の前記インデックスブロックに続く前記インデッ
クスブロックに適用される拡張型フォーマットとにより
構成されていることを特徴とする請求項１０に記載のフ
ァイル管理方法。
【請求項１２】複数の前記インデックスブロックによ
りインデックスページを形成し、前記記録媒体に、前記インデックスページにおける未使
用の前記インデックスブロックの数を表すページアカウ
ントを記録するページアカウント領域を形成することを
特徴とする請求項１１に記載のファイル管理方法。
【請求項１３】前記基本型フォーマットのインデック
スブロックは、前記ページアカウントから検索した２以
上の未使用インデックスブロックが存在する前記インデ
ックスページに記録することを特徴とする請求項１２に
記載のファイル管理方法。
【請求項１４】前記拡張型フォーマットのインデック
スブロックを記録する前記インデックスページは、１つ
前の前記拡張型フォーマットのインデックスブロックま
たは基本型フォーマットの前記インデックスブロックが
属する前記インデックスページの前記ページアカウント
から昇順に検索することを特徴とする請求項１２または
１３に記載のファイル管理方法。
【請求項１５】前記インデックスブロックには、前記
属性コードとして、ディレクトリファイルであるか否か
を表すコードを記録し、前記ディレクトリファイルのデータとして子ファイルの
インデックス番号を記録し、前記子ファイルの前記インデックスブロックには、前記
インデックスタグとして、前記ディレクトリファイルの
インデックス番号を記録することを特徴とする請求項１
０に記載のファイル管理方法。
【請求項１６】前記ディレクトリファイルのデータと
して、前記子ファイルのインデックス番号とともに、前
記子ファイルの名称を記録することを特徴とする請求項
１５に記載のファイル管理方法。
【請求項１７】前記属性コードは、複数の種類の前記
ディレクトリファイルのいずれかを表す複数ビットのコ
ードであることを特徴とする請求項１５または１６に記
載のファイル管理方法。