UDF Ver.1.5の新機能VATとスペアリング テーブル
 というのがVer.1.02までの、AVDPから順にデータを読みに行くという、UDFのごく基本的な構造ですが、それでVer.1.5におけるCD-R/RW対応とは、いったいどのような仕組みで達成したのでしょうか。それは、「VAT」と「Sparing Table=スペアリングテーブル」という二つの技術が中心になっています。

●VAT(Virtual Allocation Table)

 VATとは「Virtual Allocation Table」。シーケンシャルライトのメディアをあたかもランダムリードライトのメディアに見せてしまう技術で、「仮想アドレスをテーブルで管理する」というものです。CD-Rのパケットライト時に利用されます。

 先ほど、ISO 13346ではデータを書き換えたらICBを書き換えるだけでいいということを説明しました。CD-Rは一度しかかけないメディアですから、WORMと同じようにLBNが一つ大きいセクタに新しいICBを書けばいいのでしょうか? これは実はうまくいきません。WORMというメディアはセクタごとに記録をすることができ、記録されているセクタの間に記録されていないセクタが存在することもできます。たとえばLBN0、1、2、と6以降が記録されていて、3、4、5は未記録というようなことができるのです。しかし、シーケンシャルライトなメディアであるCD-Rではこのようなことは許されていません。つまり、未記録の部分を空けておき、ICBに変更があったら記録するというWORM用の仕組みは使えないということになります。

OSTA UDF Ver.1.5の基本構造

 そこで以下のような仕組みを使います。まず、ICBを書いたら、ICBが書いてあるセクタのLBNをあるテーブルに書き込みます。そしてICBのセクタのLBNを書くべきところに、テーブルの行番号を書いておきます。実際にICBをアクセスするときには行番号からテーブルを引いてを本当のLBNを得てアクセスします。ICBを書き換えた場合はテーブルのみを書き換えます。こうすると、すべてのICBの書き換えは新しいICBの追記と一つのテーブルの書き換えのみで行えるようになります。このテーブルがVATです。UDFVer.1.5ではVATも一つのファイルとして管理されています。ファイルであるということは、このファイルを指すICBがあるということですが、このICBはVAT ICBと呼ばれています。もちろんVAT ICBに書かれているVATのアドレスはVATを使わなくてもアクセスできる本当のLBNです。VAT ICBは常に記録済みのいちばん最後のセクタに置くことになっています。

 光ヘッドはまず、ディスクのいちばん最後を見に行きます。ここにはVAT ICBがあって、VATが読み込まれ、つぎにAVDPを読みに行きます。ADVPの示すルートディレクトリにはファイルID(FID)がありますが、FIDとICBの間にVATがあると、ポイントされるアドレス先が変換されます。つまり、「親から子」へのポインタをFIDとICBの間でいったん断ち切ってVATを置き、このVATでICBのアドレスをすり替えることによって書き換えられたように見せているわけなのです。こうすることで、たとえばルートディレクトリの中身を変えたためICBの場所が変わっても、FIDを書き換えることはなくなります。

 もっとも、ファイルを消去したり書き換えたつもりであっても、実体は存在していてソフトウエア的に読めないだけですから、消去と書き換えをくり返すと、書き換え型のメディアと違い、当然ながらメディアの残容量が減っていくので注意が必要です。

 このVATの処理はCD-Rというメディアに特有のものです。UDF Ver.1.5やUDF Ver.2.0の対応を標榜するOSであっても、MOやDVD-RAMのみの対応でVATに対応していないとCD-Rは読めないということもあります。

OSTA UDF Ver.1.5の仕組み

 もう一つ、UDFでは可変長パケットを使っているのに、なぜバッファアンダーランエラーが起きないかということをご説明します。実はバッファアンダーランは起こっているのですが、完全にリカバリができるため、ユーザにはエラーの報告がなされないのです。というのは、UDFではディレクトリ構造を最後に書き込むことができ、ICBを使ってファイルを複数の部分に分割できるため、書き込み時の時に生じたエラーなどをうまく処理できるからです。たとえば何かのファイルを書き込んでいるとき、ある領域間でデータ転送に失敗し、書き直しをしてパケットが二つに分かれてしまったとします。この場合、ファイルのデータを書き終わった後に、そのファイルは二つの部分からできているということをディレクトリに記録します。読み出す側にはファイルが分かれているのは最初から意図されて分けてあるのか、エラーで分かれてしまったのかの判断はつきません。結果、エンドユーザからするとバッファアンダーランエラーは起きていないように見えることになります。