第4章 フロッピーディスク形式

4.1 概要

TRON仕様では、 データの交換媒体であるフロッピーディスクの標準形式を規定している。 これは、基本的にアプリケーションプログラム、 およびアプリケーションデータの交換用フロッピーディスクに対してのみ適用されるが、 マシンに依存したシステムフロッピーディスク等の場合も同一形式であることが望ましい。

フロッピーディスクのセクタは 物理ブロックとも呼び、 物理的なアクセスの単位となる。 また、論理的なアクセス/アドレシングの単位を 論理ブロックと呼び、 連続した n 個の物理ブロック(セクタ)から構成される。 論理ブロックの大きさは標準フ ロッピーディスクでは 1024 バイトとする。

単にブロックといった場合は論理ブロックを示し、 論理ブロック単位のアドレスをブロックアドレスと呼ぶ。

最大論理ブロック数、 最大ファイル参照カウントの制限を緩和した拡張形式がある。 拡張形式も基本的には標準形式と同一である。 拡張形式に関しては、標準形式と異なる部分のみ記述する。

4.2 ファイルシステム構成

4.2.1 全体構成

標準フロッピーディスクは以下に示す全体の構成を持つ。

4.2.2 システムブロック構成

システムブロック はファイルシステム全体の情報を保持するブロックであり、 以下に示す構成を持つ。

システムヘッダは、128 バイトから構成され、以下の構成を持つ。 この部分はファイルシステムの生成時に作成され、 以後、"*" を付けたデータ以外は変更されない。

各データの内容を以下に示す。 各データは上位バイトが先(若いアドレス)にくるビッグエンディアン形式である。

TRONディスクID:

TRON仕様OSを示す下記の固定データである。

標準形式の場合	0x42FE
拡張形式の場合	0x52FE

ディスク形式ID:

ディスク形式を示すIDであり、下記の固定データである。

標準形式の場合	0x6400
拡張形式の場合	0x6401

システムブロックサイズ:

システムブロックの論理ブロック数である。

ファイルIDテーブルサイズ:

ファイルIDテーブルの論理ブロック数であり、 以下の計算式により求まる値を整数に切り上げした値である。

SFIDT	= (最大ファイル数×ファイルIDテーブルの1エントリバイト数) / 論理ブロックのバイト数
	= (NFMAX×4)/1024

ファイル短縮名テーブルサイズ:

ファイル短縮名テーブルの論理ブロック数であり、 以下の計算式により求まる値を整数に切り上げした値である。

SFNMT	= (最大ファイル数×ファイル短縮名テーブルの1エントリバイト数) / 論理ブロックのバイト数
	= (NFMAX×4)/1024

ビットマップのサイズ:

ビットマップのサイズであり、 標準形式の場合はバイト数、 拡張形式の場合はワード数 ( 1 ワード = 4 バイト ) で表わす。
以下の計算式により求まる値を整数に切り上げした以上の値となる。

標準形式の場合
NBMP	≧ 論理ブロックの総数/8
	≧ NLB/8
拡張形式の場合
NBMP	≧ 論理ブロックの総数/32
	≧ NLB/32

論理ブロックのバイト数:

1論理ブロックのバイト数で、標準フロッピーディスクでは 1024 となる。

最大ファイル数:

1ファイルシステム内で生成できるファイルの最大数である。

使用言語:

ファイルシステムでの使用言語、 即ち使用文字コード体系を示すコードであり、 日本語コード ( 2 バイトコード体系 ) の場合は 0x0021 となる。

アクセス管理レベル:

ファイルシステム内のファイルのアクセス管理情報の設定方法を示す。 標準フロッピーの場合は、通常0とする。

0(レベル0)	アクセス管理は行なわない。
1(レベル1)	アクセス管理を部分的に行なう。
2(レベル2)	アクセス管理を完全に行なう。

論理ブロックの総数:

ファイルシステム内の論理ブロックの総数である。

空き論理ブロック数:

未使用の論理ブロック数を示し、 使用ブロックビットマップ上の "0" のビットの総数に等しい。

最新のシステムブロックの更新日時:

システムブロックの最新の更新日時であり、 1985年1月1日0時0分0秒 (GMT) からの秒数で示される。

ファイルシステムの生成日時:

ファイルシステムの生成日時であり、1985年1月1日0時0分0秒 (GMT) からの秒数で示される。

ファイルシステムの名称:

40バイトのファイルシステムの名称であり、 ファイルシステムの生成時に使用言語で示される文字コード体系により設定される。 40バイトに満たない部分には、0が詰められる。 ファイルシステムは、この名称により一意的に識別される。

デバイス所在名:

40バイトのデバイス所在名であり、 ファイルシステムの生成時に使用言語で示される文字コード体系により設定される。 40バイトに満たない部分には、0が詰められる。 標準フロッピーの場合は、"フロッピーディスク" となる。

ビットマップは論理ブロックの管理に使用され、 使用ブロックビットマップと不良ブロックビットマップの2つがある。

1 つの論理ブロックが1つのビットに一対一対応し、 使用ブロックビットマップでは、"0" で未使用、 "1" で使用中または不良を示し、 不良ブロックビットマップでは、 "0" で正常、"1" で不良を示す。 不良ブロックに対応する使用ブロックビットマップ上のビットは、 必ず "1" に設定される。

4.2.3 ファイルIDテーブル

ファイルIDテーブルは、 そのファイルシステム内に存在するファイルの開始ブロックアドレス (3バイト) とファイルの参照カウント (1バイト) をファイル ID 順に並べたテーブルであり、 システムヘッダ内にある最大ファイル数分のエントリから構成される。

ファイルの参照カウントは、 そのファイルを参照している同一ファイルシステム内の固定リンク数を示す。 参照カウント0は、 どこからも参照されておらずファイルが削除可能であることを示す。

標準形式では、最大ファイル参照カウントは 255 となる。 拡張形式では、ファイル参照カウントが 255 以上になった場合は、 ファイルIDテーブルのファイル参照カウント値を 255 とし、 実際の参照カウント値 ( 255 以上 ) をファイルヘッダへ記録する。

標準フロッピーでは、 最大ファイル数は NFMAX であり、 ファイル ID テーブル全体は (NFMAX×4) バイトから構成される。

ID に対応する 4 バイトのエントリが0の場合は、 未使用エントリを意味する。

4.2.4 ファイル短縮名テーブル

ファイル短縮名テーブルは、 そのファイルシステム内に存在するファイルのファイル名を短縮化 (ハッシュ化) した4バイトの値をファイル ID 順に並べたテーブルであり、 システムヘッダ内にある最大ファイル数分のエントリから構成される。

標準フロッピーでは、 最大ファイル数は NFMAX であり、 ファイル短縮名テーブル全体は (NFMAX×4) バイトから構成される。

40 バイトのファイル名全体は各ファイルのヘッダ部分に入るが、 このテーブルはファイル名によるファイルの検索を高速に行なうために使用される。

ファイル短縮名は以下の方法により生成される。

1. ファイル名を 4 バイトずつパックした以下のような 32 ビットデータの配列を NAME[10] とする。 ファイル名が 40 バイトに満たない場合は 0 が詰められる。 図 62 : NAME[10]
2. 初期値を 0 とし、NAME[] の各要素と順番に排他的論理和を取りながら、 右に 1 ビット回転シフトすることにより得られたデータをファイル短縮名とする。即ち、短縮名は以下の手続で得られる。

   短縮名 = 0;
   for (i = 0; i < 10; i++) {
   	短縮名 = 短縮名 ^ NAME[i];
   	短縮名 を右に1ビット回転シフトする。
   }
   

4.2.5 ファイル領域

ファイル領域にはそのファイルシステム内のすべてのファイルが入り、 その先頭にはルートファイルが必ず存在する。 ルートファイルはファイルシステムの生成時(フォーマット時) に自動的に生成されるファイルで以下の特徴を持つ。

• ファイルID = 0
• ファイル名はシステムブロックのファイルシステム名と同一
• 参照カウント = 1

4.3 ファイル構成

4.3.1 全体構成

1 つのファイルは、順序付けられたレコード列から構成され、 1 つのレコードは可変長のバイト列から構成される。 1 つのファイルは、ヘッダブロック、データブロック、インデックスブロック、 および間接ブロックから構成され、 その構成はインデックスレベルと呼ぶ値により異なる。 インデックスレベルはレコードインデックスの多重度を示す値で、 レコードの数に応じて動的に変化する。 インデックスレベルが 0 , 1 , 2 の場合のファイルの構成を以下に示す。

なお、リンクファイルはヘッダブロックからのみ構成される。

4.3.2 ヘッダブロックの構成

ファイルのヘッダブロックは、以下に示す構成となる。

4.3.3 ファイルヘッダの構成

ファイルヘッダは 192 バイトで構成され、 ファイルの各種の管理情報が保持されている。 以下にファイルヘッダの内容を示す。

各データの内容を以下に示す。 各データは上位バイトが先(若いアドレス)にくる ビッグエンディアン形式である。

ファイルヘッダ開始ID:

0x54726f6e の固定パターン

ファイルタイプ / 属性:

ファイルのタイプ、属性、および所有者アクセスモードを示す以下の形式のデータである。

TTTT  xxxx BAPO xRWE

T : ファイルタイプ	0 リンクファイル
	1 通常ファイル
	2〜 予約
P : 削除不可属性
O : 変更(書込)不可属性
A : アプリケーション属性1
B : アプリケーション属性2
RWE : ファイル所有者のアクセスモード
x : 予約 (0)

リンクファイルの場合はファイルタイプ以外は意味を持たず0に固定される。

アプリケーションタイプ:

アプリケーションが設定するファイルのタイプ。
リンクファイルの場合、対象とするファイルのアプリケーションタイプが入る。

所有者名:

グループ名:

グループアクセスレベル:

一般アクセスレベル:

ファイルのアクセス管理情報であり、 ファイルシステムのアクセス管理のレベルに従って設定される。 リンクファイルの場合は意味を持たず、すべて0に固定される。

含まれるリンク数:

ファイルに含まれているリンクレコードの数を示す。 リンクファイルの場合は意味を持たず、0に固定される。

インデックスレベル:

レコードインデックスの多重レベルを示す。 リンクファイルの場合は意味を持たず、0に固定される。

ファイルの総バイト数:

ファイルに存在するレコードのレコード長の合計バイト数を示す。 リンクレコードのサイズは含まない。 リンクファイルの場合は意味を持たず、0に固定される。

総使用論理ブロック数:

ヘッダブロックを含んだ、 ファイルに割り当てられている論理ブロックの総数を示す。 リンクファイルの場合は1に固定される。

総レコード数:

ファイルに存在するレコードの総数を示す。 リンクファイルの場合は意味を持たず、0に固定される。

保存期限:

ファイルの保存期限であり、アプリケーションにより使用される。 ファイルの生成時には-1が設定される。 リンクファイルの場合は-1のままで更新されることはない。

最新のアクセス日時:

ファイル内のレコードデータを参照した、 あるいはファイル管理情報を更新した最新日時であり、 1985年1月1日0時0分0秒 (GMT) からの秒数で示される。
ファイルの生成時には初期値として生成日時が入る。 リンクファイルの場合は生成時の初期値のままで更新されることはない。

最新の更新日時:

ファイル内のレコードデータの最新更新日時であり、 1985年1月1日0時0分0秒 (GMT) からの秒数で示される。
ファイルの生成時には初期値として生成日時が入る。
リンクファイルの場合は生成時の初期値のままで更新されることはない。

ファイルの生成日時:

ファイルの生成日時であり、 1985年1月1日0時0分0秒 (GMT) からの秒数で示される。
リンクファイルの場合はリンクファイル自身が生成された日時が入る。

ファイル名:

40 バイトのファイル名であり、 40 バイトに満たない場合は 0 が詰められる。
リンクファイルの場合はリンクファイル自身が生成された時点での対象とするファイル名が入る。

合言葉:

暗号化済みの 24 バイトの合言葉であり、 存在しない場合は0が詰められる。存在するか否かは実際には、 先頭の1バイトが0か否かで判断される。 ファイルの生成時には存在しないため0が詰められる。

ファイル参照カウント: 拡張形式の場合のみ使用される。
ファイル参照カウントが 255 以上になったとき、 その参照カウント数を記録する。 ファイル参照カウントが 255 未満のときは0を設定する。 つまり、このフィールドは、0または 255 以上の値が設定され、 1〜254が設定されることはない。

ファイルID:

ファイルのファイルIDである。 これは、ファイルシステムの故障等が起きた場合に、 ファイルシステムを復旧するためにファイルヘッダ内に保持される。

ファイルヘッダ終了ID:

0x82dde96b の固定パターン

リンクファイルの場合は、 ファイルヘッダに続くフラグメントテーブルの部分に以下に示す 90 バイト対象ファイルの所在を示すファイル所在データが入る。 各データは上位バイトが先 (若いアドレス) にくるビッグエンディアン形式である。

対象ファイルID:

対象とするファイルが存在するファイルシステムでのファイルID。

対象ファイルの生成日時:

対象とするファイルの生成日時。

対象ファイルシステム名 :

リンクファイルが生成された時点で、 対象ファイルが存在していたファイルシステムのファイルシステム名。

対象ファ イルシステムのデバイス所在名:

リンクファイルが生成された時点で、 対象ファイルが存在していたファイルシステムのデバイス所在名。

4.3.4 フラグメントテーブルの構造

フラグメントテーブルは、 レコードの削除/サイズ縮小等によって発生した 1 つの論理ブロック内の断片的な空き領域 (フラグメント) を登録するテーブルであり、 レコードの追加 / サイズ拡張で新たな領域が必要となった場合参照されるテーブルである。

このテーブルには現在そのファイルに対して割り当てられている論理ブロック中の空き領域 (フラグメント) が最大 32 個まで登録される。 フラグメントが 32 個以上となった場合は、もっともサイズの小さいフラグメントはテーブルから取り除かれる。

レコードの削除 / サイズ縮小等が行なわれていない場合でも、 通常は、最後に書き込んだブロックの残り領域が 1 つのフラグメントとして登録されることになる。

フラグメントテーブルは以下に示す構成をとり、 各エントリは 6 バイトから構成される。 未使用エントリは、フラグメントサイズ = 0 で示される。 エントリは、必ずサイズの大きい順に並び、 途中に未使用エントリが入ることはない。 即ちフラグメントサイズ = 0 のエントリがあった場合は、 それ以後のエントリはないものと見なされる。

リンクファイルの場合は、 フラグメントテーブルの代わりにファイル所在データが入る。

4.3.5 レコードインデックスの構成

レコードインデックスは各レコードの管理情報を保持している 16 バイトのインデックスである。 インデックスレベル = 0 の場合は、 ヘッダブロックに最大 40 個のレコードインデックスが入り、 インデックスレベル < 0 の場合は、 インデックスブロックに入る。

1つのレコードが複数の論理ブロックにまたがる場合は、 通常のレコードインデックスの直後に接続インデックスと呼ぶ論理ブロックの割り当て情報を示すインデックスエントリが続く。 この接続インデックスは内部的なものであり、 レコードの数としてはカウントされない。

以下に各レコードインデックスの構成を示す。

各データの内容を以下に示す。 各データは上位バイトが先 ( 若いアドレス ) にくるビッグエンディアン形式である。

レコードタイプ:

レコードのタイプ ( 0 〜 31 ) を示すデータで、以下の形式を持つ。

100T TTTT

T:レコードタイプ	0 リンクレコード
	1〜 その他のレコード

リンクレコードの場合のレコードインデックスの形式は特殊なものとなる。

レコードサブタイプ:

レコードのサブタイプを示すデータであり、 その内容はレコードタイプにより規定される。

開始オフセット:

レコードが論理ブロックの先頭から始まっていない場合に、 論理ブロックの先頭からのバイト数を示す、 0〜(論理ブロックサイズ-1)の値。

レコードサイズ:

レコードの長さをバイト数で表わしたもの。

連続カウント:

論理ブロックアドレスから連続して何ブロック割り当てられているかを示す 0 〜 255 の値で、 0 は論理ブロックが割り当てられていないことを意味する。
論理ブロックアドレスを X とした場合、 以下の論理ブロックが割り当てられていることを示す。

	割り当てられている論理ブロック
連続カウント 1	X
連続カウント 2	X, X+1
連続カウント n	X, X+1, ... X+n-1

論理ブロックアドレス:

レコードに割り当てられている 3 バイトの論理ブロックアドレスを示す。

ファイルID:

リンクが示すファイルのファイルID。

属性データ:

リンクレコードの属性データ(1〜5)。

レコードインデックスの形式は、先頭の2バイトの値により決められる。

4.3.6 間接インデックスの構成

間接インデックスは、インデックスレベル >0 の場合に使用され、 レコードインデックスを含む論理ブロックを示す以下の 8 バイトのエントリである ( 1 論理ブロックに 128 個、ヘッダブロック内は 80 個)。

最初の 4 バイトのデータは、 間接インデックスで示される間接ブロックまたはインデックスブロックが含む有効なレコード数 (接続インデックス、 未使用インデックスを除いたレコードインデックスの数) を示す。 これは、 レコードの位置によるシークを行なう場合に使用される。

論理ブロックアドレス = 0 の間接インデックスは未使用エントリと見なされ、 未使用インデックスは、 論理ブロック内の任意の位置に存在してよい。 なお、 間接ブロック中で使用されていない部分は、 すべて未使用エントリで埋められていなければいけない。

レコードインデックスの最大数はインデックスレベルの値により以下のようになる。

4.3.7 レコードインデックスの実際

レコードインデックスとデータブロックとの対応の例を以下に示す。

レコードインデックスは、 ヘッダブロックまたはインデックスブロックの中で、 レコード順に並べられているが途中 ( 最初、最後も含む ) に任意個の未使用インデックスが入っていてもよい。 ただし、 接続インデックスは、 通常インデックスの直後から隙間無く連続して入っていなくてはいけない。 接続インデックスが複数の論理ブロックにまたがる場合でも、 論理ブロックの切れ目(最後、最初)に未使用エントリが入ってはいけない。

なお、 インデックスブロック中で使用されていない部分は、 すべて未使用インデックスで埋められていなければいけない。

インデックスレベル = 1 で、以下の状態の場合を考える。

この例で、 110番目のレコードをアクセスしたい場合は、 110-53-42=15から、 インデックスブロックCの15番目のレコードインデックスを使用することになる。

また、10番目のレコードの直前にレコードを追加した場合は、 インデックスレコードAを2つに分割 ( 通常は2等分 ) しインデックスブロックA' と A''を生成して、 間接インデックスに登録することになる。 レコードの追加後の状態は以下に示す通りとなる。

4.3.8 データブロックの構成

データブロックにはレコードの実際のデータが、 レコードインデックスで示されたブロック、 オフセットに入るが、 1つの論理ブロック内のフラグメントを管理するために、 1つの論理ブロック内のレコードとレコードの境界には空き領域を示す 2 つの区切りコードを格納する必要がある。

区切りコードは空き領域のサイズをバイト数で示した2バイトのコードであり、 空き領域の先頭と最後にそれぞれ入る。 レコードとレコードの間が隙間無く詰まっている場合は値 0 の区切りコードが連続して2つ入ることになる。 論理ブロックの先頭、および最後の区切りレコードは省略される。

以下に1つの論理ブロック内の区切りコードを示す。 図で、→はレコードインデックス内のオフセットを意味し、 ⇒はフラグメントテーブル内のオフセットを示す。 いずれの場合も区切りコードの直後の位置を示す。

1 つの論理ブロック内の隣接する空き領域は常にマージされ 1 つの空き領域にまとめられるため、 2 つ以上の空き領域が連続して存在することはない。

レコードの生成、追加、削除、サイズ変更、再配置等の操作では、 区切りコードを正しく設定し直す必要があり、 その結果、論理ブロック全体が空き領域となった場合はそのブロックを解放することになる。

付録 A 準標準フロッピーディスク形式

TRON 標準フロッピーディスク形式では、 異なるプロセッサ間を含めたフロッピーディスクの交換を完全に保証するために 8 ビット以上のビット長を持つデータのバイトオーダーは、 上位バイトが先にくるビッグエンディアン形式に統一している。

しかしながら、 この形式はリトルエンディアン形式の CPU 上で動作する BTRON では負担となる場合もあるため、 これを救済するために、 リトルエンディアンのデータ形式を持つフロッピーディスク形式を、 準標準フロッピーディスク形式として規定する。

準標準フロッピーディスク形式は、 TRON 標準フロッピーディスク形式に対して以下に示す変更 / 制限を行なったものである。

1. 使用する文字コードは2バイトの固定長とし、 かつ第2バイトが先にくる形式とする。 すなわち、文字コードはリトルエンディアンの 16 ビットデータとみなす。
2. 2バイト以上のデータのバイトオーダーは、 下位バイトが先にくるリトルエンディアン形式とする。 文字列データには、1.で記述した2バイト固定長の文字コードのみを使用する。

システムヘッダの TRON ディスク ID、 およびディスク形式 ID のバイトオーダーにより、 TRON 標準フロッピーディスク形式か、 準標準フロッピーディスク形式かの識別が行なわれる。 すなわち、BTRON標準の場合は、0x42, 0xFE, 0x64, 0x00 であり準標準の場合は、0xFE, 0x42, 0x00, 0x64 となる。

準標準フロッピーディスク形式に基づいたシステムは、 以下の点を遵守しなくてはいけない。

• 何らかの方法により、 標準フロッピーディスク形式との双方向の変換機能を有していること。
• 準標準フロッピーディスク形式である旨を明記すること。
• 標準フロッピーディスク形式との変換方法を明記すること。

本仕様書の中で、 ビッグエンディアン形式によって記述された図は、 準標準フロッーディスクにおいては、 M(Most Significant Bit) と L(Least Significant Bit)の表記が逆になる。 ここではそのすべてを掲げないが、 その一例として、 準標準フロッピーディスク形式によるレコードインデックスの構成を示す。

また、システムブロックにおけるビットマップ構成は、以下のようになる。

付録 B フロッピーディスク形式の実現例

TRON標準フロッピーディスク形式の仕様に基づいて実現された フロッピーディスクのいくつかの例をあげる。