JPH09139052A - フアイル管理方法 - Google Patents

Abstract

(57)【要約】 【課題】論理アドレスと物理アドレスとの関係に変更が
あつた場合、当該関係を管理するB*Tree全体を書き換え
る必要があつた。 【解決手段】フアイルデータが格納されるブロツクの論
理アドレスと物理アドレスとの対応関係をB*Treeで管理
するのに加えて、B*Treeを構成する各ノードに格納され
るブロツクの論理アドレスと物理アドレスとの対応関係
をノード・テーブルで管理するようにする。これにより
B*Treeを構成するノードの一部に書き換えが生じた場合
にも、当該ノードに分割や分離が生じていない限り、当
該書き換えに係るノードとこれを管理するノード・テー
ブルだけを書き換えるだけで良くなる。

Description

【発明の詳細な説明】

【０００１】

【目次】以下の順序で本発明を説明する。 発明の属する技術分野 従来の技術 発明が解決しようとする課題 課題を解決するための手段 発明の実施の形態 （１）デイスク状記録媒体 （１−１）ＣＤ−Ｒデイスクの論理構造（図１〜図５） （１−２）アドレス管理方法（図６） （２）光デイスク装置 （２−１）装置の全体構成（図７及び図８） （２−２）ＣＤ−Ｒフアイルシステム（ＣＤＲＦＳ）に
よるアドレス管理機構 （２−２−１）基本構造（図９） （２−２−２）キヤツシユ・マネジヤー （２−２−３）シーケンス・マネジヤー （２−２−３−１）B*Tree（図１０〜図１３） （２−２−３−２）B*Tree管理機構（図１４及び図１
５） （２−３）ＣＤ−Ｒフアイルシステム（ＣＤＲＦＳ）を
用いる場合の記録データ構造 （２−３−１）概略構成 （２−３−２）プライマリー・ボリユーム・デイスクリ
プター（PVD ）（図１６〜図１８） （２−３−３）スーパー・ブロツク（図１９〜図２１） （２−３−４）ノード・テーブル（図２２） （２−３−５）B*Treeインデツクス・ノード（図２３及
び図２４） （２−３−６）Sequence B*Tree リーフ・ノード（図２
５及び図２６） （３）実施例のフアイルシステムを用いる効果 （４）他の実施例 発明の効果

【０００２】

【発明の属する技術分野】本発明は、例えば追記型デイ
スク（以下、ＣＤ−Ｒ（Compact Disc write once Read
memoey ）デイスクという）のフアイル管理方法に適用
して好適なものである。

【０００３】

【従来の技術】今日、画像や文書等を永久保存するのに
適した記録媒体としてＣＤ−Ｒデイスクが注目され実用
化され始めている。ところでこのＣＤ−Ｒデイスクは一
箇所に一度だけ書き込みが可能なデイスクであるため、
データの内容が更新された場合にも同一ブロツクに書か
れたデータを書き直すことができない。このためデータ
の内容を書き換える際には、書き換えたいデータを含ん
だブロツクのデータを未使用領域に書き直さなければな
らない。加えて、このようにブロツクの位置に移動があ
ると、移動したブロツクの位置を指し示すブロツクアド
レスについても移動先のブロツクアドレスに書き換えな
ければならなくなる。

【０００４】ところがこの参照情報の書き換えは、ある
位置を変えたブロツクを参照するブロツクが20あれば20
個全てについて書き換えを行なわなければならなくな
る。なお書き換え対象であるかかる参照が格納されてい
るブロツクがさらに他のブロツクで参照されているので
あれば、さらにそのブロツクについても書き換え作業が
必要となる。このように参照の書き換えがさらに次の参
照の書き換えを引き起こし、書き換えは参照関係の整合
がとれるまで続くという問題があつた。

【０００５】

【発明が解決しようとする課題】そこで一般にはブロツ
クへの参照情報をメデイア上の物理的な位置と切り離す
ことで、このような参照情報の書き換えに係るデータの
書き換え回数を最小限にとどめる工夫がなされている。
すなわち論理的な位置と物理的な位置との対応関係を表
によつて管理し、参照作業は論理的な空間上で行うよう
になされている。これにより実際にデータが書き込まれ
ているブロツクの物理的は位置が変化した場合にも対応
表のみを書き換えることで全ての参照関係のつじつまを
合わせることが可能となる。

【０００６】このようにフアイルシステムのような構造
の変化が動的で複雑であるようなデータを扱うものを実
現するためには論理アドレスと物理アドレスの管理機構
が不可欠である。ＣＤ−Ｒフアイルシステム（以下、Ｃ
ＤＲＦＳという）は、このアドレス管理機構をフアイル
システム側でもつことにより、この問題を解決してい
る。一般にこのような１対１の対応関係は配列を用いて
管理することが多いが、メデイア上に大きな連続領域を
必要とする。そこでＢ* Treeと呼ばれる管理手法を用い
ることによつて分散した領域に対応関係を記録すること
が考えられるが、かかるＢ* Treeはデータの更新のたび
に各ノード間の参照情報の修正を必要とし、沢山のブロ
ツクを書き換えなければならないという問題があつた。

【０００７】本発明は以上の点を考慮してなされたもの
で、従来に比して論理アドレスと物理アドレスの対応関
係の書き換えが少なくて済むフアイル管理方法を提案し
ようとするものである。

【０００８】

【課題を解決するための手段】かかる課題を解決するた
め本発明におけるフアイル管理方法においては、フアイ
ルデータが格納されるブロツクの論理アドレスと物理ア
ドレスとの対応関係をB*Treeで管理すると共に、当該B*
Treeを構成する各ノードに格納されるブロツクの論理ア
ドレスと物理アドレスとの対応関係をノード・テーブル
で管理するようにする。従つてB*Treeを構成するノード
の一部に書き換えが生じた場合にも、当該ノードに分割
や分離が生じていない限り、当該書き換えに係るノード
とこれを管理するノード・テーブルだけを書き換えるだ
けで済む。

【０００９】

【発明の実施の形態】以下図面について、本発明の一実
施例を詳述する。

【００１０】（１）デイスク状記録媒体 （１−１）ＣＤ−Ｒデイスクの論理構造 まず図１にＣＤ−Ｒデイスクの論理構造を示す。このう
ち図１（Ａ）は最上位の論理構造を表し、図１（Ｂ）、
（Ｃ）及び（Ｄ）はそれぞれさらにその下位に属する論
理構造を表している。さて図１（Ａ）に示すように、Ｃ
Ｄ−Ｒデイスクにはデイスクの内周側から外周方向へ１
又は複数の記録領域を記録できるようになされている。
これら記録領域は最内周から外周方向に対して順に第１
セツシヨン、第２セツシヨン、第３セツシヨン……と呼
ばれる。

【００１１】ここで各セツシヨンはリードインエリア
（Lead In Area）、プログラムエリア（Program Are
a）、リードアウトエリア（Lead Out Area）によつて構
成される。ただしＣＤ−Ｒデイスクの場合、リードイン
エリアとリードアウトエリアとに関してはプログラムエ
リアについてデータの書き込みが終了した時点で書き込
みが開始される。このため全てのデータが書き込まれて
いない状態ではＣＤ−ＲＯＭデイスク駆動装置で読むこ
とができない。

【００１２】なお第１セツシヨンのさらに内周にはＰＣ
Ａ（Power Calibration Area）とＰＭＡ（Program Memo
ry Area ）とが設けられている。これらはそれぞれレー
ザパワーの調整用及び各セツシヨンの管理用に使用され
る領域である。さて各セツシヨンのプログラムエリア
は、図１（Ｂ）に示すように、それぞれ１又は複数のト
ラツクによつて構成され、さらに各トラツクは図１
（Ｃ）に示すようにインデツクス領域と複数のパケツト
領域とで構成される。現在の規格では図１（Ｃ）に示す
インデツクス領域に「write method」と呼ばれるパケツ
トの種別を表す情報と、「paket length」と呼ばれるア
ドレス変換用の情報とを記録するようになされている。

【００１３】ここでパケツトの種別には図２に示す固定
長パケツトの他、図３に示す単一パケツトや図４に示す
ように可変長パケツトがある。図２に示す固定長パケツ
トは「Addressing Method-II」に対応するパケツト構造
であり、図３や図４に示す単一パケツトや可変長パケツ
トはそれぞれ「Addressing Method-I 」に対応するパケ
ツト構造である。従つて「write method」に固定長パケ
ツトの記載があれば、読み出し対象であるトラツクがＣ
Ｄ−Ｒの規格に準拠したアドレス構造を採ることが分か
る。

【００１４】また「paket length」に記載されるパケツ
ト長とは、図１（Ｄ）に示す各パケツト内のユーザデー
タ領域を構成するブロツク領域の個数のことであり、ア
ドレスを発生する際に使用される。なおこれらユーザデ
ータ領域の前後には図５に示すようにパケツト間の接続
用にリンク領域が設けられており、それぞれリンクブロ
ツク（Link Block）、ランインブロツク群（Run-in Blo
cks ）、ランアウトブロツク群（Run-out Blocks）と呼
ばれている。この例ではリンク領域として７ブロツクが
割り当てられている。以上がＣＤ−Ｒデイスクに用いら
れる論理構造である。

【００１５】（１−２）アドレス管理方法 次に「Addressing Method-I 」及び「Addressing Metho
d-II」のそれぞれによるアドレスの与え方を図６を用い
て説明する。ただし図６において横軸（ＨＡ：Header A
ddress）は物理アドレスを表し、縦軸（ＬＢＮ：Logica
l Block Number）はコンピユータ側が管理する論理アド
レスを表しているものとする。さて「Addressing Metho
d-I 」は物理アドレスと論理アドレスとの間に線形性が
認められる領域であり、図中では「02:02:00」までの領
域が該当する。

【００１６】一方、「Addressing Method-II」は物理ア
ドレスと論理アドレスとの間に線形性が認められない領
域であり、図中では第２トラツクの固定パケツト群がこ
れに対応する。すなわち「Addressing Method-II」では
リンク領域のアドレスを論理アドレス上同じアドレスと
みなすように処理している。図中ではこのリンク領域の
部分で物理アドレスと論理アドレスとを対応付ける線分
が階段状になつている。なお先頭パケツトにはこれらリ
ンク領域がないので「Addressing Method-I 」であつて
も「Addressing Method-II」であつても論理アドレスに
対応する物理アドレスに差はなく、同じ物理アドレスが
対応する。

【００１７】（２）光デイスク装置 （２−１）装置の全体構成 図７にデイスク駆動装置を外部記憶装置として用いる光
デイスク装置１の構成例を示す。光デイスク装置１は小
型コンピユータ２を中心に構成され、小型コンピユータ
２にモニタ３、入力装置４及びＣＤ−Ｒデイスク駆動装
置５Ａ、ＣＤ−ＲＯＭデイスク駆動装置５Ｂを接続して
構成されている。

【００１８】ここでＣＤ−Ｒデイスク駆動装置５Ａ及び
ＣＤ−ＲＯＭデイスク駆動装置５Ｂは小型コンピユータ
２に対してインターフエース２Ｅ２を介して接続されて
おり、ＣＰＵ２ＡはＲＡＭ２Ｂ上で実行されるソフトウ
エアプログラムに基づいてＣＤ−Ｒデイスク駆動装置５
ＡやＣＤ−ＲＯＭデイスク駆動装５Ｂを駆動するように
なされている。このときソフトウエアプログラムの構造
は図８に示すようになる。

【００１９】さらにＣＰＵ２Ａにはインターフエース２
Ｅ１を介して内蔵型のハードデイスク駆動装置２Ｆが接
続され、ここから各種周辺機器を駆動するプログラム等
が読み出されて実行されるようになされている。またＲ
ＯＭ２ＣにはＢＩＯＳ（Basic In Out System ）が記憶
されており、起動時に読み込まれるようになされてい
る。

【００２０】（２−２）ＣＤ−Ｒフアイルシステム（Ｃ
ＤＲＦＳ）によるアドレス管理機構 （２−２−１）基本構造 次にＣＤ−Ｒフアイルシステムについて説明する。ＣＤ
−Ｒフアイルシステムのアドレス管理機構は、図９に示
すように、シーケンス・マネジヤー（SequenceManage
r）とキヤツシユ・マネジヤー（Cache Manager ）との
２つのモジユールによつて構成される。このうちシーケ
ンス・マネジヤーは論理アドレスと物理アドレスとの対
応表をB*Treeを用いて管理している。なおシーケンス・
マネジヤーの論理空間は64ビツトで表され、そのうち上
位32ビツトはフアイルの指定に、下位32ビツトはフアイ
ル内におけるブロツクの指定に使用されるようになされ
ている。すなわち64ビツトの論理空間は32ビツトの物理
空間に対応付けられるようになされている。

【００２１】（２−２−２）キヤツシユ・マネジヤー キヤツシユ・マネジヤーはその名の通り、データのキヤ
ツシユ機構である。このＣＤ−Ｒフアイルシステムでは
データのＣＤ−Ｒデイスクからの読み出し及びＣＤ−Ｒ
デイスクへの書き込みをこのキヤツシユ・マネジヤーを
通じて行なう。例えばキヤツシユ・マネジヤーは指定さ
れた物理アドレスのデータブロツクを返す。実際の物理
アドレスはそのブロツクがＣＤ−Ｒデイスクに書き込み
終わるまで確定しないので、データの変更が生じたブロ
ツクや新たに生成されたブロツクに対して仮の物理アド
レスが割り当てられる。キヤツシユ・マネジヤーはデー
タがメデイアに書き込まれるまで仮物理アドレスによつ
てこれらのブロツクを管理する。

【００２２】このときシーケンス・マネジヤーは物理ア
ドレスが実在の物か仮の物なのかは区別することなくデ
ータブロツクにアクセスすることができる。なおキヤツ
シユ・マネジヤーはブロツクをＣＤ−Ｒデイスクに書き
込む直前に書き込み予定位置を決定する。決定された書
き込み予定位置は、シーケンス・マネジヤーの管理表に
も反映される。実際の書き込みが成功すると、予定位置
は実際の物理アドレスとなる。

【００２３】（２−２−３）シーケンス・マネジヤー （２−２−３−１）B*Tree さてＣＤ−Ｒフアイルシステムの論理空間はシーケンス
・キー（Sequence Key）と呼ばれる64ビツトの論理アド
レスによりブロツク単位で管理される。ここで１ブロツ
クは2048バイトでなる。このうちシーケンス・キーの上
位32ビツトはシーケンス番号（Sequence Number ）と呼
ばれ、同じシーケンス番号をもつブロツクの集合はシー
ケンス（Sequence）と呼ばれる。さてフアイルには固有
のシーケンス番号が対応し、１つのフアイルは１つのシ
ーケンスとして管理される。

【００２４】一方、シーケンス・キーの下位32ビツトは
シーケンス・ブロツク番号（Sequence Block Number ）
と呼ばれ、シーケンス内のブロツクを指定するのに用い
られるようになされている。ここで１つのシーケンスが
持つことのできるブロツクの数は2³² であるから、ＣＤ
−Ｒフアイルシステムが管理できるフアイルの大きさの
上段は８テラバイトとなる。このようにシーケンス・マ
ネジヤーは論理アドレスであるシーケンス・キーと物理
アドレスとの対応関係を図１０に示すB*Treeを用いて管
理するモジユールである。ただし本発明に係るシーケン
ス・マネジヤーはさらにB*Treeを管理テーブルで管理す
ることにより書き込み回数の削減を実現している。

【００２５】さてシーケンス・マネジヤーが管理するB*
Treeのノードは2048バイト、すなわち１ブロツクであ
る。これらノードは、図１１及び図１２において「Ｄ」
〜「Ｇ」で示すように、中間ノードであるインデツクス
・ノード（Index Node）と、実際に論理・物理アドレス
情報の入るリーフ・ノード（Leaf Node ）との２種類か
らなる。ここでインデツクス・ノードはノードへの参照
をインデツクス（Index ）という形式で１７０個持つこ
とができ、リーフ・ノードは論理・物理アドレス情報を
エクステント（Extent）と呼ばれる形式で１４５個持つ
ことができる。なおB*Treeの基本特性から各ノード内に
格納されているインデツクスやエクステントの個数は通
常２／３であり、最悪でも半分は埋まるようになされて
いる。

【００２６】因にエクステントはデータブロツクの論理
アドレスであるシーケンス番号と物理アドレスであるＬ
ＢＡとの対応を示すデータ構造であり、シーケンス番
号、ＬＢＡ及び長さ（Length）からなる。ここで長さ
（Length）は、連続したシーケンス番号のデータブロツ
クがＬＢＡで示される物理アドレスから何ブロツク連続
しているかを示している。これはエクステントの個数を
減らすための工夫である。例えばシーケンス番号が「 1
2345678h」、ＬＢＡが「 1000h」、長さが「 5」で与え
られるエクステントによつて図１３に示す５つの対応関
係を１つのエクステントで表現することができる。

【００２７】（２−２−３−２）B*Tree管理機構さてB*
Treeを構成しているデータもＣＤ−Ｒデイスク上に記録
されているので データ内容の更新に伴う参照の書き換えが起きる。そこ
でB*Treeを構成しているデータブロツクについても論理
アドレスと物理アドレスとの対応表とその管理機構が必
要となる。このＣＤ−ＲフアイルシステムではB*Treeを
構成するブロツクにノード番号（Node Number ）と呼ば
れる32ビツトの論理アドレスを付け、これと物理アドレ
スとの対応表を論理アドレスを添字にした配列テーブル
によつて管理するようにする。この配列テーブルはノー
ド・テーブル（Node Table）と呼ばれ、本発明に係るフ
アイルシステムの中核になるテーブルである。この管理
表の例を図１４に示す。

【００２８】因に図１４に示すノード・テーブルの場
合、「entry [0]=30」より、ノード番号「 0」のB*Tree
ブロツクは物理アドレスの「30LBA 」に記録されている
ことが分かる。なおノード・テーブルには配列テーブル
以外に２つのデータが付随している。また「number of
entry 」は配列の要素数を示し、「Free Entry」は配列
内における未使用要素リストの先頭を示している。ここ
で未使用要素リストとは、配列内で使われていない要素
の管理機構であり、配列要素の再利用を簡単にする効果
がある。

【００２９】なお未使用要素の中身にはブロツクアドレ
スの代わりに次の未使用要素の添字が入つている。因に
最後の未使用要素の中身には配列の要素数「number of
entry 」が入つている。この例ではtable[2]が未使用要
素リストの先頭であり、以下、table[4]、table[1]とな
る。ところでノード・テーブルはデイスク上の連続領域
に記録する必要がある。なぜなら不連続領域に記録でき
るようにするには、さらに管理機構が必要となつてシス
テムが複雑になるからである。

【００３０】なおB*Treeに変更が生じてB*Treeを構成す
るブロツクの書き換えがあつた場合には、やはりノード
・テーブルを更新してデイスクに書き込む必要が生じる
のであるが、このノード・テーブルの存在により書き換
えが必要になるブロツクの波及を最低限に抑えることが
できるといつた効果が得られる。これを次に説明する。
ここではB*Treeが１ギガバイトのデータを管理している
ものとし、その際に必要なブロツク数の最大値を求め
る。このとき最大値が得られるのは、各エクステントが
１つのブロツクを参照し、各ノードが半分しか使用され
ていないときである。

【００３１】するとリーフ・ノードのブロツク数及び各
階層のインデツクス・ノードのブロツク数は図１５に示
すように与えられ、B*Treeが管理するブロツク数は全体
で8095〔block 〕であることが分かる。なおB*Treeを構
成するブロツク１つにつき論理アドレスを添字にした配
列テーブルには４バイトが必要である。従つてB*Treeを
管理するノード・テーブルの大きさは、最悪の場合で
も、次式

【数１】 に示すように16〔block〕となる。すなわち１ギガバイ
トの空間を管理するB*Treeであつてもこれを管理する管
理テーブルに必要な連続領域はたかだか16ブロツクであ
ることが分かる。

【００３２】因にこのＣＤ−Ｒフアイルシステムの場
合、１パケツトは３２ブロツクであつたからノード・テ
ーブルは１パケツトに納めることができる。なおＣＤ−
Ｒフアイルシステムでは、フラツシユ動作時やイジエク
ト動作時、ＣＤ−Ｒデイスクに書き出す最後のパケツト
にその他の管理情報と共にこのノード・テーブルを納め
るようになされている。このように本発明に係るＣＤ−
Ｒフアイルシステムのデータブロツクの論理・物理アド
レス管理機構においては、B*Treeとノード・テーブルと
の２重構造を採用した。

【００３３】それはB*Treeを使わずに、ノード・テーブ
ルのような単純な配列テーブルだけを用いて論理・物理
アドレス管理機構を実現しようにすると、非常に大きな
連続領域が必要になつてしまうからである。例えば前述
の場合と同様、１ギガ空間を管理する場合の最悪条件を
考えると、1024ブロツクもその連続領域が必要になつて
しまう。またB*Treeのみで管理しようとすると、B*Tree
ノードをＬＢＡで参照することになり、B*Treeノードの
更新の度に参照の書き換えが他のB*Treeノードに波及す
る問題があるからである。

【００３４】（２−３）ＣＤ−Ｒフアイルシステム（Ｃ
ＤＲＦＳ）を用いる場合の記録データ構造 （２−３−１）概略構成 最後にＣＤ−Ｒフアイルシステムに基づいてデイスク上
に記録されるデータ構造を説明する。このＣＤ−Ｒフア
イルシステムではデータを、プライマリー・ボリユーム
・デイスクリプター（PVD:Primary Volume Descriptor
）、スーパー・ブロツク（Super Block ）、ノード・
テーブル（Node Table）、B*Tree・インデツクス・ノー
ド、シーケンス・B*Tree・リーフノード、デイレクトリ
ー・B*Tree・リーフノードの６つによつて管理する。

【００３５】なおノード・テーブル（Node Table）を除
く全てのデータ構造は１ブロツク（2048〔byte〕）の大
きさを有し、ブロツク境界に記録される。またノード・
テーブルは１ブロツク以上の大きさの可変長データ構造
をとり、その先頭はブロツク境界から始まる。

【００３６】（２−３−２）プライマリー・ボリユーム
・デイスクリプター（PVD ） このデータは、図１に示した各セツシヨンの先頭から16
ブロツク目に記録される。なお先頭の1152バイトには
「ISO9660 」のPVD と同じデータが記録されており、11
53バイト目以降にＣＤ−Ｒフアイルシステムに固有の情
報が格納されるようになされている。図１６に、プライ
マリー・ボリユーム・デイスクリプターに書き込まれる
データ例を示す。

【００３７】例えば「1152」〜「1156」の「File Syste
m Standard ID」には、用いられるフアイルシステムの
種別が記録される。「1157」の「File System Versio
n」にはバージヨン情報が記録され、「1174」の「Copyr
ight 」には権利者名が記録される。「1174」の「Super
Block Search Method 」には、最新の「Super Block
」がどこに格納されているかを示す情報が記録され
る。一例を図１７に示す。

【００３８】「1188」、「1189」の「File System Flag
s」にはトラツクのデータ構造が記録される。一例を図
１８に示す。「1190」、「1191」の「Packet Size」に
は「Fixed Packet」を構成するユーザデータのブロツク
数が記録される。ただしこの情報は「File system Flag
s」の記述が「Adressing Method II 」のときのみ有効
である。「1192」〜「1195」の「Volume Capacity 」に
はフオーマツト後のメデイアに記録できるユーザデータ
の総ブロツク数が記録される。ただしこの値はＯＳ（Op
erating System）に対してメデイアの総容量を返す際に
利用される参考値であり、必ずしも正確な値ではない。

【００３９】（２−３−３）スーパー・ブロツク スーパー・ブロツクに記述されるデータ内容の例を図１
９に示す。ここで「 0」〜「63」の「Super Block Head
er」には文字列が記録され、当該ブロツクがスーパー・
ブロツクであるかどうか認識できるようになされてい
る。なお前項で述べたプライマリー・ボリユーム・デイ
スクリプター（PVD ）に「Search Method= 1 」と記載
されている場合には、何らかの不具合で「Super Block
Header」を頼りに過去の「Super Block 」をサーチす
る。なお「64」、「65」の「Super Block Vresion 」に
ついては現時点で使用方が未定である。

【００４０】また「66」、「67」の「Super Block Flag
s」には、「Virgin Session 0x0001」が記録され、セ
ツシヨンに有効なデータが記憶されていないこと分か
る。このとき「Current Super Block 」における「Supe
r Block Flags 」に「VirginSessionフラグ」がオン状
態になつているメデイアに対して、書き込み可能状態
（オープンセツシヨン）でのフリーズ動作を行なおうと
してもＣＤＲＦＳはなにもしない。ただし書き込み禁止
（クローズセツシヨン）のためのフリーズ動作は有効で
ある。

【００４１】「68」〜「71」の「Node Table LBA」は
「Node Table」が記録されているブロツクを示す。大き
さが２ブロツク以上の場合、「Node Table」は「Node T
able LBA」が示すブロツクから連続的に記録される。
「72」〜「75」の「Previous Super Block LBA」は前回
記録された「Super Block 」の位置を示す。ＣＤ−Ｒメ
デイアの場合、いつたん記録されたデータはメデイア上
から失われることがないため、「Previous Super Bloc
k」をたどることによつて過去の「Volume」の状態を知
ることができる。「76」〜「79」の「Suquence B*Tree
Root Node Number」は「Suquence Manger」が管理して
いる「Suquence B*Tree 」の「Root Node 」の「Node N
umber 」を示す。

【００４２】「80」〜「83」の「Directory B*Tree Roo
t Node Number」は「File Manger 」が管理している「D
irectory B*Tree」の「Root Node 」の「Node Number」
を示す。「84」〜「87」の「Serial Number 」は「Supe
r Block 」の通し番号である。なおフオーマツト時に生
成される「Super Block 」の「Serial Number」は
「０」である。「88」〜「487」の「Super Block Lis
t」は過去５０の「Previous Super BlockLBA」を集めた
テーブルであり、図２０に示すような「Super Block Li
st Entry」の繰り返しである。

【００４３】このうち「Super Block List」の最初のエ
ントリーは「Super Block List」を納めている「Super
Block 」の１つ前の「Super Block 」である。またエン
トリーは、「Super Block 」のSerial番号の降順に並ん
でいる。過去の「Super Block 」が５０に満たない場
合、エントリーは先頭から詰められ、未使用のエントリ
は「０」で埋められる。

【００４４】「488 」〜「2023」の「Super Block Tag
List」は過去の「Super Block 」の名称ラベル（Tag)の
テーブルであり、図２１に示すような「Tag Entry 」の
繰り返しである。なおＣＤ−Ｒフアイルシステムでは１
つのメデイアに最大２４個の名称ラベル（Tag ）を付け
ることができる。因に名称ラベル（Tag ）の個数が２４
個に満たないときは、エントリーは先頭から詰められ、
未使用のエントリは「０」で埋められる。

【００４５】（２−３−４）ノード・テーブル ノード・テーブルは前述したように「Sequence B*Tre
e」のノードのノード番号と記録位置（ＬＢＡ）の対応
表である。連続領域に図２２に示すようなフオーマツト
で記録される。なお「Node Table」はデータブロツクの
先頭から連続的に記録され、もし１つのデータブロツク
に収まりきらない場合には次のデータブロツクに続きが
記録されるようになされている。

【００４６】（２−３−５）B*Treeインデツクス・ノー
ド このノードは、B*Treeの「Leaf Node 」以外のノードで
ある。これは「Sequence B*Tree 」についても「Direct
ory B*Tree」についても共通である。一例を図２３に示
す。なおここで「 4」の「Number of Records 」は「Le
af Node 」に格納される「Index Record」の数を示し、
図２４に示すような構造をもつている。さらに「Index
Record」は「Key 」の昇順にソートされて「Index Reco
rd

〔０〕」から順に詰められて記録されるようになされ
ている。

【００４７】（２−３−６）Sequence B*Tree リーフ・
ノード このノードは、「Sequence Key」と「 LBA」の対応関係
を格納するための「B*Tree Node 」であり、この一例を
図２５に示す。なお「Index Node」内の「Extent」は
「Key 」順にソートされており、図２６に示す「Extent
Record

〔０〕」から詰めて記録されている。またノー
ド内の「Extent」の数は「Number of Records 」に入つ
ている。

【００４８】（３）実施例のフアイルシステムを用いる
効果 以上説明したように、ＣＤ−Ｒデイスク用のフアイルシ
ステムに、B*Treeとノード・テーブルとを組み合わせた
フアイル管理方法を採用したことにより、B*Treeを構成
するあるノードの内容に変更がある場合にもB*Treeを構
成する他のノードに書き換えが波及するおそれを低減で
き、最小限の書き換えで済ませるようにすることができ
る。

【００４９】この様子を図１０を例に説明する。従来の
ようにB*Treeだけで管理する場合には、インデツクス・
ノードＦの書き換えがあると、互いにリンク関係のある
ノードＤ、Ｅ、Ｇ……に書き換えの必要が生じ、総数で
考えると多くの記憶領域を消費しなければならなかつ
た。一方、今回提案した手法の場合、特に書き換え後に
おけるインデツクス・ノードＦのエクステントの個数が
格納可能な総数を越えず、ノードの分割も分離も生じな
いときにはある大きさのノードＦ及びノード・テーブル
Ｂを書き換えるだけで良い。この効果は書き換える記憶
容量が大きければ大きいほど有効である。

【００５０】（４）他の実施例 なお上述の実施例においては、ＣＤ−Ｒデイスクのフア
イル管理方法について述べたが、本発明はこれに限ら
ず、他の記録媒体についてフアイルを管理するフアイル
管理方法に広く適用し得る。また記録媒体についてもＣ
Ｄ−Ｒに限定して説明したが、これに限らず、広く光デ
イスクに適用し得る。

【００５１】

【発明の効果】上述のように本発明によれば、フアイル
データが格納されるブロツクの論理アドレスと物理アド
レスとの対応関係をB*Treeで管理すると共に、当該B*Tr
eeを構成する各ノードに格納されるブロツクの論理アド
レスと物理アドレスとの対応関係をノード・テーブルで
管理するようにしたことにより、B*Treeを構成するノー
ドの一部に書き換えが生じた場合にも、当該ノードに分
割や分離が生じていない限り、当該書き換えに係るノー
ドとこれを管理するノード・テーブルだけを書き換える
だけで済ませることができるフアイル管理方法を実現す
ることができる。

【図面の簡単な説明】

【図１】本発明に係るデイスクのデータ構造の説明に供
する略線図である。

【図２】固定長パケツト構造を示す略線図である。

【図３】単一パケツト構造を示す略線図である。

【図４】可変長パケツト構造を示す略線図である。

【図５】リンク領域部分のデータ構造を示す略線図であ
る。

【図６】２種類のアドレス管理方法を示す図表である。

【図７】光デイスク装置の構成を示すブロツク図であ
る。

【図８】ソフトウエア構造を示すブロツク図である。

【図９】本発明に係るフアイル管理方法で採用するシー
ケンス・マネジヤー及びキヤツシユ・マネジヤーの構造
を示す略線図である。

【図１０】B*Treeのデータ構造を示す略線図である。

【図１１】本発明に係るフアイル管理方法が管理するデ
ータ構造を示す略線図である。

【図１２】本発明に係るフアイル管理方法が管理するデ
ータ構造を示す略線図である。

【図１３】エクステントの構造を示す図表である。

【図１４】ノード・テーブルの構造を示す図表である。

【図１５】B*Treeを構成するブロツク数の求め方を表す
略線図である。

【図１６】プライマリー・ボリユーム・デイスクリプタ
ーのデータ構造を示す図表である。

【図１７】スーパー・ブロツク・サーチ・メソツドの欄
に記述される内容を示す図表である。

【図１８】フアイル・システム・フラグの欄に記述され
る内容を示す図表である。

【図１９】スーパー・ブロツクに記述される内容を示す
図表である。

【図２０】スーパー・ブロツク・リスト・エントリーに
記述される内容を示す図表である。

【図２１】タグ・エントリーに記述される内容を示す図
表である。

【図２２】ノード・テーブルに記述される内容を示す図
表である。

【図２３】B*Treeインデツクス・ノードを示す図表であ
る。

【図２４】インデツクス・レコードを示す図表である。

【図２５】B*Treeリーフ・ノードを示す図表である。

【図２６】エクステント・レコードを示す図表である。

【符号の説明】

１……光デイスク装置、２……小型コンピユータ、３…
…モニタ、４……入力装置、５Ａ……ＣＤ−Ｒデイスク
駆動装置、５Ｂ……ＣＤ−ＲＯＭデイスク駆動装置。

Claims (3)

【特許請求の範囲】
1. 【請求項１】フアイルデータが格納されるブロツクの論
   理アドレスと物理アドレスとの対応関係をB*Treeで管理
   すると共に、当該B*Treeを構成する各ノードに格納され
   るブロツクの論理アドレスと物理アドレスとの対応関係
   をノード・テーブルで管理するようにしたことを特徴と
   するフアイル管理方法。
2. 【請求項２】上記フアイルデータは、追記型記録媒体に
   記憶されていることを特徴とする請求項１に記載のフア
   イル管理方法。
3. 【請求項３】上記ノード・テーブルは記録媒体上の連続
   領域に記録されることを特徴とする請求項１に記載のフ
   アイル管理方法。