cloopfs: cloopfs の欠陥 ― 2006年05月11日 09時32分22秒
それに加えて、バージョン番号を保持していない。こちらも、かなり致命的な欠陥である。どこで、見かけたかは覚えていないが、既にこの形式が三番目のものであるらしい。悪いがβ版の物にしか見えない。拡張性を持たせたいのであらば、バージョン番号は必須である。余談ではあるが、TCP/IP にも各パケット毎にバージョン番号は記録されている。
さて、以上の考察を参考に変更すると、
[header][block-indexes][blocks...]
から
[header[version number][address of block-index]][block-indexes][blocks...]
[header[version number][address of block-index]][blocks...][block-indexes]
とすると、とても融通が効くようになる。変更点は、バージョン番号をヘッダに組み込んだのと、block-index の始まる位置をヘッダに入れたことである。
さて、新しく提示した形式に二つの例を上げた。block-index 自体は連続して割り当てなければならないが、block-index の位置は何にも縛られない。blocks の前に置くことも、後に置くことも可能である。何せ、そのためにわざわざ位置を記録しているのであるから。
なお、各ブロックは完全に独立している点に注意して欲しい。この点は、元の cloop でも同じである。それ故、block-index が前に来ようが後に来ようが何の影響もない。
さらに、これを発展させると、block-index に同じ値が入っていても構わないのである。例を上げると、index 2 と index 10 が同じ位置の 16384 を指していても問題ないのである。どちらの index も、読込むために必要な位置を表している。それらの位置情報はお互いに被依存関係かつ完全独立なので、偶然にも内容が完全に一致する場合は、複数の index から同一の block を指していても、何ら問題はないのである。現実的には、有用な情報の書かれているディスクだとそのような状況は、滅多に御目にかかれない。しかし、まだ、何も書かれていない領域は話が別だ。すなわち、全てが 0 の領域である。
実は、似た様な提案は昔にも出ていたらしい。しかし、それに続く返事と現在の状況を見ると、取り上げられることは無かったのであろう。詳しく見てみると、三つ上げている具体案のどれもが uyota 流と違う。
そこから引用すると、
cloopfs は大容量の bootable-CD を最初に実現したという点は、特筆すべき事実である。残念ながら、そのデザインと実装は大変陳腐なものである。デザインは拡張性に乏しく、実装は多大な資源を浪費する。8 bit でもバージョン番号に割り当てるだけで、まったく互換性の無い形式を次世代に開発できるようになる。また、たった 64 bit の block-index への位置情報を保持するだけで、これまた cloopfs の作成が格段と容易になる。たった、72 bit と思慮の差で、デザインというものは雲泥の差が出てしまう。肝に命じておきたいものだ。
とある。確かに彼の三つの提案だと、どれも反対意見を覆すことは出来ない。どれも block-index への位置情報を持たないからだ。それに比べると、uyota 流は version information は header に位置し、block-index も先頭に置きたければ、可能である。
- a version number is included in the header
- the index is at the end of the file, followed by
- a number that indicates the exact position of the start of the index.
while Klaus objected:
think that stuff like version information or indexes really belong to
the beginning of a file, not at the end, so you still can access them if
later parts of the file are corrupted.
最近のコメント