web archive
[digg.com] "Why FAT is so popular if it is sucks so bad?"
紹介したし、ちょっと 訳してみます。
http://digg.com/linux_unix/New_Linux_patch_could_circumvent_Microsoft_s_FAT_patents?t=26682369#c26682708
Bowie 07/02/2009
たぶん Microsoft の 崇拝者? (fanboy) たちは、FAT が それほど ひどいものなら、どうして こんなに 一般的 (popular) なのかを 説明してみろ、と 質問攻めに 合わせるだろう。 そう、これは ほんの 一例だ。
FAT ファイルシステムで ファイルを 保存するとき、ファイルは ディスク (platter) 上の 最初の 利用可能な 場所に 書き込まれる。 もし 1つの ファイルを 他の 別のものの 後に 次々 書き込むなら、 次の ファイルは 前の ファイルの 末端 (end) から 少し 離れて 置かれるので、これは 都合が いい。 分割は 起こらない。 だが FAT で ファイルを 削除するとき 何が 起きるのだろう? それは これらの 領域 (area) が (再び) 利用可能なことを 示す。 そう、別の ファイルを 書き込むものと 考えてみよう -- 驚くことに、それは 同じ アルゴリズムである -- ファイルは ディスクの 最初の 利用可能な 場所に 書き込まれる。 つまり 少なくとも ファイルの 一部は 削除され 残った 空いている 断片 (hole) の 中に 書き込まれる
...もしも 書き込まれた ファイルが その 断片より 大きければ、ファイルは すぐに 分割される。 たとえ ディスク上の どこかに ギガバイト以上の 空いている 余地が あったとしても、書かれた ファイルは バラバラに 分割されてしまう、こちらに 書き込みを 少々、あちらに 書き込みを 少々...ファイルの 一部は 使用後に 削除した 場所に 置かれ、他の 部分は どこか 別に 置かれる。 今や、こうした 行程 (process) が 数十万回 繰り返される (multiply)。 常に ファイルは 書き込まれ そして 削除される。 知らないうちに、書き込まれた すべての 呪われた ファイルは 散弾のように ディスク上に ばらまかれ、時間を 費して せっせと つくった 愛すべき Excel の スプレッドシートの 断片を 拾いあげ、それらの 位置 1つ 1つを すべて ドライブヘッド (drive head) が 捜し出すには、比較的 (relatively) 膨大な 時間が かかるのだ。 もっとも 小さな ファイルから 最大の ものまで、すべてが ネズミの 巣のように からまっている。1MB の ファイルを 読むのに、ドライブ (ヘッド) は 1つの 小さい KB を そして 次から 次へ より 多くの 小さい KB (を 求め) 別の 場所に 移動し、ディスク上の 1000 近くの 異なった 位置を 捜す 必要に みまわれるだろう。 容量 (cache) が 十分だとしても、こうした 探索の やり方は、実行 (performance) の 見地からすれば バカバカしいほど 貧弱だ。 それは おそろしく 効率が 悪い。今度は これを、Unix では この 仕事を ファイルシステムが どう 扱うかと 比較してみる。 再び、ディスクは 新しい (clean) ものとして 考える。 1ダースの ファイルを ディスクに 書き込むとき、重複 (overlap) の 可能性を 防ぐため、これらの ファイルの 位置は わざと できるだけ 切り離される。 ファイル、次の ファイル、その 次と 書き込まれ、そして この すべての 変更 (change) で ファイルの 間には 隔たり (distance) が ある。 この やり方により 断片 (化) は ゼロに 近く、アクセスする 時間は 高速に、そして (ドライブ) ヘッドによる 読み書きが イライラする バグのため 時間を ムダに することが ないので、I/O の 速度は 高速に なる。 その 結果、Unix では 断片 (化) は ファイルシステムが 満杯に 近づいたとき -- このときだけ 1つの ファイルは 細断され ディスクの まだ 捜せる 空いている 空間に 散らばらなくては (spread) いけない。 探索 (seek) は どんな 保存形態に おいても 第一の 敵だ -- (ドライブ) ヘッドが 望む データが どこに 位置するかを 捜し回る (travel) のに どれほどの 時間が かかるだろうか。
今の ハードディスクでは、探索する 時間は 近接する (neighbourhood) か その 周囲では 5ms か それくらいだろう。 5ミリセカンドは 読み取りに かかる、そして データを 装置に 送る 時間と 比べれば とてつもなく 長い。 最高の 性能を (引き出す) ためには、探索状態の 時間が できるだけ 少なく 費される ファイルシステムが 望ましい。
仮りに データの 読み出しを ラジオを 聞くことと 関連づけるなら、FAT とは 大好きな 歌が 3秒ごとに、30分の コマーシャルの カタマリで 中断される AM局だろう。 それは、まったく あってはならない。 どんなときも、その すべての 形態において FAT を 避けるべきだ。 それは NTFS を 含む。
少しでも 気づこう (reading) 。 それが 重要だ。 なぜなら、誰も 気づかなければ、1981年に 橋から 投げ捨てられるべきだった ファイルシステムを、2009年に 使っているため、今や 動きが とれない (be stuck) からだ。
(追記) ちょっと 訂正。
