[b-free 605] Re: ファイルシステムに求められるもの

Takanori Hayashi (takanori@ohsaki.meidensha.co.jp)
Wed, 24 Sep 1997 18:33:32 +0900

林です。

In message <199709220225.LAA13155@hisoft.soft.hitachi.co.jp>
"[b-free 569] Re: ファイルシステムに求められるもの"
"Ryuichi Naitoh <naitoh_r@soft.hitachi.co.jp>" wrote:
naitoh_r> うーん、BTRON でのファイルの使い方にもよりますけど、512B 程度の小さい
naitoh_r> ファイルを多く使うのであれば、ブロックの最低の大きさを小さくする必要が
naitoh_r> 出てきます。BSD UNIX だと、ブロックの大きさが 4KB または 8KB で、更に
naitoh_r> 小さな断片ブロック(512B または 1KB) というのを定義しています。
naitoh_r> 古い UNIX だと、断片ブロックはなく、単にブロックのサイズが 512B または
naitoh_r> 1KB になっていました。

単にブロックサイズを小さくするより断片ブロックみたいな
小さいファイル専用のブロックを作る方が良さそうですね。
あるいは別の構造を作って小さいファイルはブロックに関係
なく詰め込めるようにする。512B程度のファイルになると
ヘッダが無視できなくなるからヘッダもコンパクトにできる
ような方式があると効率は上げられると思います。実行効率
は逆に落ちるかも知れませんが。

ファイルシステムサイズとファイルサイズについて
naitoh_r> > 最大 (2^63-1)byteかな。10GBからこのサイズまでに実装上の
naitoh_r> > 手間が大きく変わる点ってありましたっけ。
naitoh_r>
naitoh_r> 場合によっては、管理用の情報のサイズが増えるかもしれませんが、実装上の
naitoh_r> 手間はほとんど増えないと思います。

ではできるだけ大きくいきましょう(^_^)。

naitoh_r> > 現在の感覚では実用上は十分そうだけど、ディスクサイズが
naitoh_r> > 上のサイズになると(当分ならないだろうけど)、1ファイル
naitoh_r> > 平均2GBになる。やっぱり最大 (2^63-1)個の口か。
naitoh_r>
naitoh_r> ファイルの最大数は、ファイルシステムの大きさによって可変にするのがいいかも
naitoh_r> しれませんね。
naitoh_r> 1GB のディスクに (2^63-1) 個のファイル分のテーブルをもちたくないし。。。

可変はもちろんですね。1Bもそうだし。ファイルの(ヘッダ
を含めた)占有サイズに下限があるので作れる最大ファイル数
はだいたい計算できます。
上記の最大はファイルIDに64bit値を使う必要があることです。
# これも現状のサイズからいえば結構無駄かも。

naitoh_r> > そうそうディスクに最大ファイル数個のIDテーブルを持つ
naitoh_r> > のは何とかならないでしょうか。
naitoh_r>
naitoh_r> この辺は、ファイルシステムの形式の問題ですね。
naitoh_r> API とは関係ないので、個々のファイルシステムの設計で工夫できると思います。

まあそうですが。作れる最大ファイル数と実際に使う
ファイル数の差が大きいと結構無駄が大きくなるので大規模
ディスクでは基本的に対処をして欲しいですね。

naitoh_r> > ただサイズ無制限のファイル名だと、ファイル名の取得の
naitoh_r> > インターフェースに工夫が要ります。今のままだと用意する
naitoh_r> > べきバッファサイズが分からないので。またむやみやたらに
naitoh_r> > 大きなバッファを要求するのも問題なので指定したバッファ
naitoh_r> > に入る分だけの名前を返せるようにする必要もあるでしょう。
naitoh_r> > # 指定したオフセットから…。
naitoh_r> > # ここまでやるとデータ読み取りと区別がつかん(^_^;)。
naitoh_r>
naitoh_r> ここまでファイル名に制限を加えないのならば、むしろ属性の一部というより、
naitoh_r> ファイルのデータの一部と考えた方がいいのでは?
naitoh_r> パス名からファイルを検索するのは、データの検索と同様に扱えばいいと思い
naitoh_r> ます。
naitoh_r> (おぉ、データベースファイルシステムに近くなりましたね)

属性とデータの区別も難しいですが、長いファイル名は
構造的にデータと同じ扱いでも良いでしょう。検索の高速
化への対処もあまり長いと難しいと思うし…。

---
    林(takanori@ohsaki.meidensha.co.jp)