Mac関連ネタを凄い勢いで翻訳するスレ・４
>>226 と同じサイトにある、興味深い記事を翻訳しました。
ttp://www.kernelthread.com/mac/apme/fragmentation/
HFS+の断片化
ファイルの断片化はパフォーマンスを低下させるとよくいわれている。
普通、モダンなファイルシステムは古いファイルシステムよりも断片化しにくくなっている。
断片化の進行を抑えたり解消するために、数多くの機構がファイルシステムに組み込まれているからだ。
それでもなお、エンドユーザーはもちろんファイルシステムの設計や実装においても
相変わらず断片化は不安材料のままである。
● この記事の目的：
・HFS+ボリュームの内部を探るためのツール、hfsdebug の紹介
・HFS+で断片化の度合いを測定し、結果を示す。
/*
断っておくが、私はHFS+の断片化抑制機構にケチをつけるつもりはない。
ここでの結果は手持ちの数ボリュームを解析しただけのものだ。この記事は、ボリュームの状態を探る方法や
hfsdebugの使用例を見せるのが主眼である。
*/
● hfsdebug
断片化状況を調べるのに、私が作ったHFS+デバッガ、 hfsdebug を使う。
hfsdebugには断片化状況の表示以外にも様々な機能があり、HFS+の仕組みを知るのにちょうどいいツールになっている。
この記事で示されているデータはすべてこのツールを使って得たものだ。
/*
もっと詳しく知りたいなら、hfsdebugのページを読んでほしい。この記事で述べられている
断片化度合の測り方を理解したいのなら一読するべきだろう。
*/
ttp://www.kernelthread.com/mac/apme/fragmentation/
HFS+の断片化
ファイルの断片化はパフォーマンスを低下させるとよくいわれている。
普通、モダンなファイルシステムは古いファイルシステムよりも断片化しにくくなっている。
断片化の進行を抑えたり解消するために、数多くの機構がファイルシステムに組み込まれているからだ。
それでもなお、エンドユーザーはもちろんファイルシステムの設計や実装においても
相変わらず断片化は不安材料のままである。
● この記事の目的：
・HFS+ボリュームの内部を探るためのツール、hfsdebug の紹介
・HFS+で断片化の度合いを測定し、結果を示す。
/*
断っておくが、私はHFS+の断片化抑制機構にケチをつけるつもりはない。
ここでの結果は手持ちの数ボリュームを解析しただけのものだ。この記事は、ボリュームの状態を探る方法や
hfsdebugの使用例を見せるのが主眼である。
*/
● hfsdebug
断片化状況を調べるのに、私が作ったHFS+デバッガ、 hfsdebug を使う。
hfsdebugには断片化状況の表示以外にも様々な機能があり、HFS+の仕組みを知るのにちょうどいいツールになっている。
この記事で示されているデータはすべてこのツールを使って得たものだ。
/*
もっと詳しく知りたいなら、hfsdebugのページを読んでほしい。この記事で述べられている
断片化度合の測り方を理解したいのなら一読するべきだろう。
*/
|
|
|
● hfsdebug
断片化状況を調べるのに、私が作ったHFS+デバッガ、 hfsdebug を使う。
hfsdebugには断片化状況の表示以外にも様々な機能があり、HFS+の仕組みを知るのにちょうどいいツールになっている。
この記事で示されているデータはすべてこのツールを使って得たものだ。
/*
もっと詳しく知りたいなら、hfsdebugのページを読んでほしい。この記事で述べられている
断片化度合の測り方を理解したいのなら一読するべきだろう。
*/
● 断片化とは何か
一般的に、OSはドライブの記憶領域を「小さい区画が整然と敷き詰められている」と見なす。
ハードディスクはリードアヘッド（先行読み込み）機能を持ち、大きなデータの読み書きをする際
連続した区画を一気に読み出せるようになっている。
つまりデータは連続した区画に存在するのがよいわけだ。
ディスクは、ボリュームという単位でフォーマットされる。ファイルシステムというのは
ディスクにデータを配置する仕組みのことだが、ボリュームはファイルシステムを実体化させたものといえる。
（断片化とあまり関係ない話だけど。）
まず、断片化していない状態というものを定義しよう。
データ全体が連続した区画にある状態を、断片化していない、と定義する。
/*
HFS+では、ファイルは独自に複数のフォークを持つ事ができる。
（NTFSでのマルチストリームに似ている）
MacOS Xでは従来通りデータフォークとリソースフォークのみが使われる。これ以降は
ファイルの断片化と言わず、フォークの断片化と表現することにする。
*/
断片化状況を調べるのに、私が作ったHFS+デバッガ、 hfsdebug を使う。
hfsdebugには断片化状況の表示以外にも様々な機能があり、HFS+の仕組みを知るのにちょうどいいツールになっている。
この記事で示されているデータはすべてこのツールを使って得たものだ。
/*
もっと詳しく知りたいなら、hfsdebugのページを読んでほしい。この記事で述べられている
断片化度合の測り方を理解したいのなら一読するべきだろう。
*/
● 断片化とは何か
一般的に、OSはドライブの記憶領域を「小さい区画が整然と敷き詰められている」と見なす。
ハードディスクはリードアヘッド（先行読み込み）機能を持ち、大きなデータの読み書きをする際
連続した区画を一気に読み出せるようになっている。
つまりデータは連続した区画に存在するのがよいわけだ。
ディスクは、ボリュームという単位でフォーマットされる。ファイルシステムというのは
ディスクにデータを配置する仕組みのことだが、ボリュームはファイルシステムを実体化させたものといえる。
（断片化とあまり関係ない話だけど。）
まず、断片化していない状態というものを定義しよう。
データ全体が連続した区画にある状態を、断片化していない、と定義する。
/*
HFS+では、ファイルは独自に複数のフォークを持つ事ができる。
（NTFSでのマルチストリームに似ている）
MacOS Xでは従来通りデータフォークとリソースフォークのみが使われる。これ以降は
ファイルの断片化と言わず、フォークの断片化と表現することにする。
*/
断片化にはいくつかの種類がある。
1.ユーザーレベルの断片化
たとえファイルがディスク内で連続領域にあったとしても、ユーザーから見ると連続領域にない情報を含んでいる。
例えば、あるワープロ文書がディスクの連続領域にあったとしても、ワープロソフトがそれを読み出すという
視点から見ると、それは連続しているとはいえない。
そんな断片化の量を量ったり扱ったりするのは難しく、アプリケーションやファイル形式に依存するため
たいした成果は期待できない。こういった断片化については議論しない。
（訳者註：正直、ここは意味を把握できてません...Finderでユーザーが目にするファイル配置と
ディスク内部のファイル配置が一致しないという話ではないかと...）
2.内部の断片化
HFS+ボリュームではファイルをアロケーションブロックと呼ばれる区画に割り振る。
アロケーションブロック（例えば4KB）はディスクドライバの転送単位（例えば512バイト）
の整数倍である。これらはどちらもファイルの読み書き単位：1バイトよりもはるかに大きい。
HFS+のアロケーションブロックを4KBと仮定すると、1バイトのファイルでも4KB = 4096バイトを占有する。
残りの4095バイトは、ファイルサイズが増えない限り無駄になる。このような無駄を内部断片化と呼ぶ事がある。
この記事ではHFS+の内部断片化を計算する。
（訳者註：32MB以上の容量があるHFS+ボリュームは、アロケーションブロック=4KBになると思います）
/*
BSDのUFS（MacOS Xでもサポートしている）はアロケーションブロックに加え、
別のアロケーションユニット：フラグメントを持つ。フラグメントはアロケーションブロックの分数
（例えば、ブロックの1/8）である。
ファイルシステムが複雑になってしまうが、ボリュームに小サイズのファイルが大量にあるときに効果を発揮する。
*/
1.ユーザーレベルの断片化
たとえファイルがディスク内で連続領域にあったとしても、ユーザーから見ると連続領域にない情報を含んでいる。
例えば、あるワープロ文書がディスクの連続領域にあったとしても、ワープロソフトがそれを読み出すという
視点から見ると、それは連続しているとはいえない。
そんな断片化の量を量ったり扱ったりするのは難しく、アプリケーションやファイル形式に依存するため
たいした成果は期待できない。こういった断片化については議論しない。
（訳者註：正直、ここは意味を把握できてません...Finderでユーザーが目にするファイル配置と
ディスク内部のファイル配置が一致しないという話ではないかと...）
2.内部の断片化
HFS+ボリュームではファイルをアロケーションブロックと呼ばれる区画に割り振る。
アロケーションブロック（例えば4KB）はディスクドライバの転送単位（例えば512バイト）
の整数倍である。これらはどちらもファイルの読み書き単位：1バイトよりもはるかに大きい。
HFS+のアロケーションブロックを4KBと仮定すると、1バイトのファイルでも4KB = 4096バイトを占有する。
残りの4095バイトは、ファイルサイズが増えない限り無駄になる。このような無駄を内部断片化と呼ぶ事がある。
この記事ではHFS+の内部断片化を計算する。
（訳者註：32MB以上の容量があるHFS+ボリュームは、アロケーションブロック=4KBになると思います）
/*
BSDのUFS（MacOS Xでもサポートしている）はアロケーションブロックに加え、
別のアロケーションユニット：フラグメントを持つ。フラグメントはアロケーションブロックの分数
（例えば、ブロックの1/8）である。
ファイルシステムが複雑になってしまうが、ボリュームに小サイズのファイルが大量にあるときに効果を発揮する。
*/
3.外部断片化
一般に断片化と呼ばれているものがこれだ。
前述したように、HFS+はアロケーションブロック単位でフォークを配置する。
HFS+でのファイル配置手法はエクステント型である。エクステントとは連続したアロケーションブロックの塊で、
エクステントディスクリプタ（{ボリューム内での開始位置, ブロック数} のような形式）によって表される。
アロケーションブロックを4096バイトとすると、4ブロックだと16384バイトになる。
これらのブロックを連続させる = 4ブロック全てが1つのエクステントに収まっているのが、フォークが断片化していない状態だ。
ボリューム内での各フォークの位置はエクステントディスクリプタを使って示され、
その形式は{ボリューム内での開始位置, ブロック数}のようになっている。
16384バイト = 4ブロックのフォークが12345ブロックから開始されていると、
エクステントディスクリプタは{12345, 4} のようになる。
もしフォークが断片化していると、断片それぞれにエクステントディスクリプタが必要になる。
例えば [{12345, 2}, {23456, 2}] は、フォークが12345ブロックと23456ブロックの2カ所に断片化している状態だ。
/*
ここでは、断片という言葉をエクステントと同じ意味で使っている。
UFSにおけるフラグメントと混同しないようにしてほしい。
100%連続しているファイルというのは、本来は「ファイルが一つのエクステントに収まっている」と表現し、
追加エクステントはファイルの断片を指し示す。
*/
一般に断片化と呼ばれているものがこれだ。
前述したように、HFS+はアロケーションブロック単位でフォークを配置する。
HFS+でのファイル配置手法はエクステント型である。エクステントとは連続したアロケーションブロックの塊で、
エクステントディスクリプタ（{ボリューム内での開始位置, ブロック数} のような形式）によって表される。
アロケーションブロックを4096バイトとすると、4ブロックだと16384バイトになる。
これらのブロックを連続させる = 4ブロック全てが1つのエクステントに収まっているのが、フォークが断片化していない状態だ。
ボリューム内での各フォークの位置はエクステントディスクリプタを使って示され、
その形式は{ボリューム内での開始位置, ブロック数}のようになっている。
16384バイト = 4ブロックのフォークが12345ブロックから開始されていると、
エクステントディスクリプタは{12345, 4} のようになる。
もしフォークが断片化していると、断片それぞれにエクステントディスクリプタが必要になる。
例えば [{12345, 2}, {23456, 2}] は、フォークが12345ブロックと23456ブロックの2カ所に断片化している状態だ。
/*
ここでは、断片という言葉をエクステントと同じ意味で使っている。
UFSにおけるフラグメントと混同しないようにしてほしい。
100%連続しているファイルというのは、本来は「ファイルが一つのエクステントに収まっている」と表現し、
追加エクステントはファイルの断片を指し示す。
*/
・HFS+のフォークは複数のエクステントを持つ
・メタデータ内のファイルレコード（乱暴に例えるとiノードに似たもの）には8つまでエクステントディスクリプタを格納できる
以上の点が重要だ。もしフォークのエクステント数が8を超えていると、超過分のエクステントディスクリプタは
エクステントオーバーフローBツリーに格納され、探し出すのに時間を食うようになる。
従って、HFS+の断片化状態は以下の種類に分類される。
A. エクステントは1つ。断片化していない
B. 2〜8個のエクステントを持つ
C. 9個以上のエクステントを持つ
/*
今まで我々は「断片化していないのがいい」と言ってきた。
現代のハードディスクは読み書き要求サイズが大きい時パフォーマンスが良くなる。
ファイルが連続領域にあると読み書き要求サイズ（ただし、CPUの負荷も）が大きくなり、
ハードディスクのパフォーマンスを引き出せる。
（訳者註：ATA制御時のCPU負荷は、現在のようにCPUが十分高速だと無視できるレベルです）
*/
● 断片化を測る
2つの断片化したファイルを比較してどちらがマシかなどというのは人によってまちまちだ。
ファイルの読み出し方から見た、考え方の例を示す。
2つの断片化したファイル、X = [{x1, 500}, {x2, 500}] と Y = [{y1, 999}, {y2, 1}] を考えてみる。
どちらも2つに断片化しており、総計は1000ブロック。断片化の程度はどちらも同じだ。
ただし、ブロックをランダムに読み出すなら、Yのほうがましだろう。
なぜなら999ブロックの方が、500ブロックよりも多くの連続領域を含むからだ。
ただし、ハードディスクの最大読み書きサイズによっては違う結論になってしまうが。
結論づけると、999ブロックが連続しているYの方が一気に読み出せる可能性が高いので、Yの方が良いといえるだろう。
・メタデータ内のファイルレコード（乱暴に例えるとiノードに似たもの）には8つまでエクステントディスクリプタを格納できる
以上の点が重要だ。もしフォークのエクステント数が8を超えていると、超過分のエクステントディスクリプタは
エクステントオーバーフローBツリーに格納され、探し出すのに時間を食うようになる。
従って、HFS+の断片化状態は以下の種類に分類される。
A. エクステントは1つ。断片化していない
B. 2〜8個のエクステントを持つ
C. 9個以上のエクステントを持つ
/*
今まで我々は「断片化していないのがいい」と言ってきた。
現代のハードディスクは読み書き要求サイズが大きい時パフォーマンスが良くなる。
ファイルが連続領域にあると読み書き要求サイズ（ただし、CPUの負荷も）が大きくなり、
ハードディスクのパフォーマンスを引き出せる。
（訳者註：ATA制御時のCPU負荷は、現在のようにCPUが十分高速だと無視できるレベルです）
*/
● 断片化を測る
2つの断片化したファイルを比較してどちらがマシかなどというのは人によってまちまちだ。
ファイルの読み出し方から見た、考え方の例を示す。
2つの断片化したファイル、X = [{x1, 500}, {x2, 500}] と Y = [{y1, 999}, {y2, 1}] を考えてみる。
どちらも2つに断片化しており、総計は1000ブロック。断片化の程度はどちらも同じだ。
ただし、ブロックをランダムに読み出すなら、Yのほうがましだろう。
なぜなら999ブロックの方が、500ブロックよりも多くの連続領域を含むからだ。
ただし、ハードディスクの最大読み書きサイズによっては違う結論になってしまうが。
結論づけると、999ブロックが連続しているYの方が一気に読み出せる可能性が高いので、Yの方が良いといえるだろう。
5人が使っているMacのHFS+ボリュームを解析した。
繰り返しになるが、一般的な解を出すにはサンプルが少なすぎるので、単なる実例だと思ってほしい。
それぞれのボリュームはこんな使われ方をしている：
・iBook -- ライトユーザーが毎日使っている。ブラウジング、メール、メッセンジャー、音楽、
たまにワープロソフトやグラフィックソフトを使う。
・PowerBook 15' -- パワーユーザーが毎日仕事に使っている。ブラウジング、メール、メッセンジャー、開発、etc。
・PowerBook 17' -- 私が家で毎日使っている。ブラウジング、メール、メッセンジャー、音楽、ワープロ、
グラフィックソフト、ムービー編集、開発、etc。
・G5 -- パワーユーザーが毎日家で使っている。PowerBook 17' と似たような感じだ。
・G5 外付ディスク -- G5に接続された外付ディスク。音楽、ムービー、バックアップなどが保存されている。
いずれも、MacOS X 10.3をインストールしてから6ヶ月ほど経っている。
● 解析
最初に、ボリューム毎のおおまかな統計をとり、Table 1 に示す。Table 1 は以下のコマンドラインから得たものだ。
% hfsdebug -d /dev/rdiskN -s -t 5
N はボリュームによって異なる。例えば、MacOS Xのデフォルトでは起動ボリュームが /dev/rdisk0s9 となる。
注記：% hfsdebug -s -t 5 のように、ボリュームを指定しなくてもよい。（起動ボリュームが選ばれる）
/*
もしフォークが空か、サイズが0だと結果が全く得られない。
サイズ0のフォークは断片化している／していない、どちらでもないとする。
サイズ0のファイルが断片化していないのは明白なので、断片化していない方に勘定するという考え方ができるが、
そうしてしまうとボリュームが実際よりも断片化していないように見えてしまうだろう。
典型的なMacOS Xのインストールでは、サイズ0のデータフォークはほとんど存在せず、
逆にほとんどのリソースフォークはサイズ0だ。両方のフォークがサイズ0のファイルはごく僅かしかない。
*/
繰り返しになるが、一般的な解を出すにはサンプルが少なすぎるので、単なる実例だと思ってほしい。
それぞれのボリュームはこんな使われ方をしている：
・iBook -- ライトユーザーが毎日使っている。ブラウジング、メール、メッセンジャー、音楽、
たまにワープロソフトやグラフィックソフトを使う。
・PowerBook 15' -- パワーユーザーが毎日仕事に使っている。ブラウジング、メール、メッセンジャー、開発、etc。
・PowerBook 17' -- 私が家で毎日使っている。ブラウジング、メール、メッセンジャー、音楽、ワープロ、
グラフィックソフト、ムービー編集、開発、etc。
・G5 -- パワーユーザーが毎日家で使っている。PowerBook 17' と似たような感じだ。
・G5 外付ディスク -- G5に接続された外付ディスク。音楽、ムービー、バックアップなどが保存されている。
いずれも、MacOS X 10.3をインストールしてから6ヶ月ほど経っている。
● 解析
最初に、ボリューム毎のおおまかな統計をとり、Table 1 に示す。Table 1 は以下のコマンドラインから得たものだ。
% hfsdebug -d /dev/rdiskN -s -t 5
N はボリュームによって異なる。例えば、MacOS Xのデフォルトでは起動ボリュームが /dev/rdisk0s9 となる。
注記：% hfsdebug -s -t 5 のように、ボリュームを指定しなくてもよい。（起動ボリュームが選ばれる）
/*
もしフォークが空か、サイズが0だと結果が全く得られない。
サイズ0のフォークは断片化している／していない、どちらでもないとする。
サイズ0のファイルが断片化していないのは明白なので、断片化していない方に勘定するという考え方ができるが、
そうしてしまうとボリュームが実際よりも断片化していないように見えてしまうだろう。
典型的なMacOS Xのインストールでは、サイズ0のデータフォークはほとんど存在せず、
逆にほとんどのリソースフォークはサイズ0だ。両方のフォークがサイズ0のファイルはごく僅かしかない。
*/
---Table 1 各ボリュームの比較---
Volume Size ボリュームの容量
Volume Type ボリュームの使用形態
Boot/Root 起動ボリューム
External/Data 外付ディスク データ保存用
files ファイル
folders フォルダ
aliases エイリアス
hard links ハードリンク
symlinks シンボリックリンク
invisible 不可視
both forks empty データフォーク、リソースフォークともにサイズ0
Avg. File Size 平均ファイルサイズ
Data Forks データフォーク
Resource Forks リソースフォーク
non-zero サイズ0でない
fragmented 断片化している
allocated space 使用しているアロケーションブロックの合計
actually used 全フォークの合計
difference アロケーションブロックの合計と、全フォークの合計の差
5 Largest Files 大サイズのファイル ベスト5
Table 1 で、non-zero がサイズ0のフォークの数を示しており、fragmented が断片化したフォークを示している。
これらの数値を元に、内部断片化率を算定したものをTable 2 に示す。
---Table 2 内部断片化率---
Block Size アロケーションブロックのサイズ
Data Forks データフォークの内部断片化率
Resource Forks リソースフォークの内部断片化率
Weighted Avg. 加重平均
この内部断片化率は、各フォークのアロケーションブロック合計と、フォークの合計との差から計算されている。
Volume Size ボリュームの容量
Volume Type ボリュームの使用形態
Boot/Root 起動ボリューム
External/Data 外付ディスク データ保存用
files ファイル
folders フォルダ
aliases エイリアス
hard links ハードリンク
symlinks シンボリックリンク
invisible 不可視
both forks empty データフォーク、リソースフォークともにサイズ0
Avg. File Size 平均ファイルサイズ
Data Forks データフォーク
Resource Forks リソースフォーク
non-zero サイズ0でない
fragmented 断片化している
allocated space 使用しているアロケーションブロックの合計
actually used 全フォークの合計
difference アロケーションブロックの合計と、全フォークの合計の差
5 Largest Files 大サイズのファイル ベスト5
Table 1 で、non-zero がサイズ0のフォークの数を示しており、fragmented が断片化したフォークを示している。
これらの数値を元に、内部断片化率を算定したものをTable 2 に示す。
---Table 2 内部断片化率---
Block Size アロケーションブロックのサイズ
Data Forks データフォークの内部断片化率
Resource Forks リソースフォークの内部断片化率
Weighted Avg. 加重平均
この内部断片化率は、各フォークのアロケーションブロック合計と、フォークの合計との差から計算されている。
ボリュームに小さなファイルが多数ある場合、アロケーションブロックのサイズが大きいほど内部断片化しやすい。
サンプルのボリュームでも同じ傾向が見られる。
断片化しているファイルが何％あるかを見てみよう。Table 3 を見る限り、どのボリュームも非常に少ない。
---Table 3 断片化しているフォーク---
Data Forks データフォークの断片化率
Resource Forks リソースフォークの断片化率
Weighted Avg. 加重平均
％ Unfragmented 断片化していないファイルの割合
このように、断片化しているフォークは僅かである。
次に、断片化しているフォークを対象に、より詳しい状態を調べる。Table 4 は以下のコマンドから得たものだ。
% hfsdebug -d /dev/rdiskN -f -t 5
-f オプションは、断片化している全てのフォークを表示する。各フォークについて、出力は以下の項目で構成されている
（分析を楽にするために出力している項目もいくつかある。）
・カタログノードID
・フォークタイプ（データフォーク／リソースフォーク）
・フォークの割り当て情報。例えば、フォークが10ブロック、20ブロック、30ブロックの3つに断片化している場合、
10:20:30 のように表示される
・サイズ
・フォークが占有しているアロケーションブロック数
・フォークのエクステント数
・エクステント毎のアロケーションブロック数の平均
・ファイルのPOSIXパス
/*
/private/var/vm 以下に、多くのエクステントを持つファイルがあるだろう。これらのファイルは仮想メモリ関係のものである。
*/
サンプルのボリュームでも同じ傾向が見られる。
断片化しているファイルが何％あるかを見てみよう。Table 3 を見る限り、どのボリュームも非常に少ない。
---Table 3 断片化しているフォーク---
Data Forks データフォークの断片化率
Resource Forks リソースフォークの断片化率
Weighted Avg. 加重平均
％ Unfragmented 断片化していないファイルの割合
このように、断片化しているフォークは僅かである。
次に、断片化しているフォークを対象に、より詳しい状態を調べる。Table 4 は以下のコマンドから得たものだ。
% hfsdebug -d /dev/rdiskN -f -t 5
-f オプションは、断片化している全てのフォークを表示する。各フォークについて、出力は以下の項目で構成されている
（分析を楽にするために出力している項目もいくつかある。）
・カタログノードID
・フォークタイプ（データフォーク／リソースフォーク）
・フォークの割り当て情報。例えば、フォークが10ブロック、20ブロック、30ブロックの3つに断片化している場合、
10:20:30 のように表示される
・サイズ
・フォークが占有しているアロケーションブロック数
・フォークのエクステント数
・エクステント毎のアロケーションブロック数の平均
・ファイルのPOSIXパス
/*
/private/var/vm 以下に、多くのエクステントを持つファイルがあるだろう。これらのファイルは仮想メモリ関係のものである。
*/
---Table 4 外部断片化の分析---
fragmented 断片化しているフォークの数
with 2 extents エクステント数が2のフォーク （＝2つに断片化しているフォーク）
- do - (%) 断片化しているフォークのうち、エクステント数2のフォークが占める割合
with > 8 extents エクステント数が8を超えているフォーク （＝9つ以上に断片化しているフォーク）
- do - (%) 断片化しているフォークのうち、エクステント数8超のフォークが占める割合
Files with Most Extents 最も多くのエクステントを持つファイル（＝最も激しく断片化しているフォーク）
Total Extents エクステント数の合計
Averages 平均
Extents/Fork 断片化しているフォークの平均エクステント数
Fragmented File Size 断片化しているファイルの合計
Bytes/Extent （断片化しているフォークの）エクステントの平均サイズ
殆どのボリュームにおいて、断片化しているファイルのうち最も多いのが
"それほど細切れとはいえない”2つのエクステントを持つファイルであることがわかる。
先に述べたように、エクステントが8を超えると断片化の次の段階となるが、
そのようなフォークは一般的なボリュームでは非常に少ない。
（G5 外付ディスクのような、極端に大きなファイルが多数あると数が増えてくる）
● これらの統計は何を示しているか
測定により得られた断片化率はどれをとっても実に小さい。（他のファイルシステムとの比較は無しとして）
HFS+の設計といくつかの最適化手法（次の項に記載）は断片化の抑制を狙っている。
今回解析したボリュームを見る限りでは、断片化は狙い通り抑制されているようだ。
/*
HFS+が最先端のファイルシステムだというつもりはない。だが、現実世界において
最先端のファイルシステムは素晴らしいシステムであるとも言い切れない。
NTFSは多くの点でHFS+よりも進んでいるが、しばしば設計とかけ離れた振る舞いをする。
NTFSにあってHFS+にない機能としては、近接アトリビュート（ファイルレコードにまるごと格納される微小なファイル）、
スパースファイル、ファイル圧縮、暗号化ファイルシステム、多用途なインデックス機能やログ機能などがある。
*/
fragmented 断片化しているフォークの数
with 2 extents エクステント数が2のフォーク （＝2つに断片化しているフォーク）
- do - (%) 断片化しているフォークのうち、エクステント数2のフォークが占める割合
with > 8 extents エクステント数が8を超えているフォーク （＝9つ以上に断片化しているフォーク）
- do - (%) 断片化しているフォークのうち、エクステント数8超のフォークが占める割合
Files with Most Extents 最も多くのエクステントを持つファイル（＝最も激しく断片化しているフォーク）
Total Extents エクステント数の合計
Averages 平均
Extents/Fork 断片化しているフォークの平均エクステント数
Fragmented File Size 断片化しているファイルの合計
Bytes/Extent （断片化しているフォークの）エクステントの平均サイズ
殆どのボリュームにおいて、断片化しているファイルのうち最も多いのが
"それほど細切れとはいえない”2つのエクステントを持つファイルであることがわかる。
先に述べたように、エクステントが8を超えると断片化の次の段階となるが、
そのようなフォークは一般的なボリュームでは非常に少ない。
（G5 外付ディスクのような、極端に大きなファイルが多数あると数が増えてくる）
● これらの統計は何を示しているか
測定により得られた断片化率はどれをとっても実に小さい。（他のファイルシステムとの比較は無しとして）
HFS+の設計といくつかの最適化手法（次の項に記載）は断片化の抑制を狙っている。
今回解析したボリュームを見る限りでは、断片化は狙い通り抑制されているようだ。
/*
HFS+が最先端のファイルシステムだというつもりはない。だが、現実世界において
最先端のファイルシステムは素晴らしいシステムであるとも言い切れない。
NTFSは多くの点でHFS+よりも進んでいるが、しばしば設計とかけ離れた振る舞いをする。
NTFSにあってHFS+にない機能としては、近接アトリビュート（ファイルレコードにまるごと格納される微小なファイル）、
スパースファイル、ファイル圧縮、暗号化ファイルシステム、多用途なインデックス機能やログ機能などがある。
*/
別のファイルシステムと比較してみれば、今回の結果はより有意義なものになるだろう。
時間が許せば、いくつかの主要なファイルシステム（手始めにNTFS、ReiserFSで）で今回のような統計をとってみたい。
ただ、同等のボリューム（同じ使用期間、同じ使用パターン、etc）を見つけないといけない。
人工的に似た使い方、使用期間を再現する手もあるだろう。
● MacOS X（10.3）に組み込まれた断片化対策
先に述べたように、HFS+のファイル配置手法はエクステント形式で、各エクステントが近接している程よい。
さらに、HFS+は遅延書き込みを使用する：
メモリ上のファイルをすぐにディスクに書き込まずにファイルキャッシュに蓄積し、あるタイミングでキャッシュを一気に書き込む。
したがって、いくつかの小さな書き込みはひとまとめにされて一気に（うまくいけば連続した区画に）書き込まれる。
Appleはデフラグツールを提供していないが、10.3でいくつかの断片化抑制機構をHFS+に追加してきた。
うち２つは、一定サイズ以下かつ頻繁にアクセスされるファイルの断片化抑制／防止に重要な働きをする。
1. 即時デフラグ
HFS+上でファイルが開かれた時、以下の条件がチェックされる：
・サイズが20MB
・busy 状態でない
・読み出し専用でない
・8つを超えるエクステントを持っている
・システムが起動して3分以上経過している
これら条件に全て当てはまる場合、ファイルはその場で断片化が解消され、ディスクに再配置される。
2. ホットファイルクラスタリング（HFAC）
今のところ、この機構は起動ボリュームのみに適用される。
HFACは頻繁にアクセスされるファイルを複数のステージに分類し、ボリューム上の "ホットスペース"
（ボリューム先端にあるメタデータ領域の直後に置かれ、ボリューム容量の0.5%のサイズが確保される）に移動する。
移動されたファイルは断片化が解消される。
ステージは DISABLED、IDLE、BUSY、RECORDING、EVALUATION、EVICTION、ADOPTION などがある。
最大5000ファイル、10MB以下のファイルが対象となる。
hfsdebug を使えばHFACの動作を探ることができる。
時間が許せば、いくつかの主要なファイルシステム（手始めにNTFS、ReiserFSで）で今回のような統計をとってみたい。
ただ、同等のボリューム（同じ使用期間、同じ使用パターン、etc）を見つけないといけない。
人工的に似た使い方、使用期間を再現する手もあるだろう。
● MacOS X（10.3）に組み込まれた断片化対策
先に述べたように、HFS+のファイル配置手法はエクステント形式で、各エクステントが近接している程よい。
さらに、HFS+は遅延書き込みを使用する：
メモリ上のファイルをすぐにディスクに書き込まずにファイルキャッシュに蓄積し、あるタイミングでキャッシュを一気に書き込む。
したがって、いくつかの小さな書き込みはひとまとめにされて一気に（うまくいけば連続した区画に）書き込まれる。
Appleはデフラグツールを提供していないが、10.3でいくつかの断片化抑制機構をHFS+に追加してきた。
うち２つは、一定サイズ以下かつ頻繁にアクセスされるファイルの断片化抑制／防止に重要な働きをする。
1. 即時デフラグ
HFS+上でファイルが開かれた時、以下の条件がチェックされる：
・サイズが20MB
・busy 状態でない
・読み出し専用でない
・8つを超えるエクステントを持っている
・システムが起動して3分以上経過している
これら条件に全て当てはまる場合、ファイルはその場で断片化が解消され、ディスクに再配置される。
2. ホットファイルクラスタリング（HFAC）
今のところ、この機構は起動ボリュームのみに適用される。
HFACは頻繁にアクセスされるファイルを複数のステージに分類し、ボリューム上の "ホットスペース"
（ボリューム先端にあるメタデータ領域の直後に置かれ、ボリューム容量の0.5%のサイズが確保される）に移動する。
移動されたファイルは断片化が解消される。
ステージは DISABLED、IDLE、BUSY、RECORDING、EVALUATION、EVICTION、ADOPTION などがある。
最大5000ファイル、10MB以下のファイルが対象となる。
hfsdebug を使えばHFACの動作を探ることができる。
/*
デフラグツールはホットスペースをいじるべきではない。勝手にいじるとパフォーマンスが落ちる！
*/
● デフラグをやる人は哀れ
見てきた通り、10.3.X上のHFS+ボリュームは断片化がよく抑えられており、
デフラグツールのような高級治療薬が必要になるほど悪化するとは考えられない。
hfsdebugはボリュームの断片化ファイルを全表示し、各ファイルのエクステント数を見ることができる。
多くの要因（ファイルサイズ、ボリュームの空き領域etc）があるが、もしあなたが激しく断片化したフォークを
単純に移動、コピーして新しい名前をつけるとする。
その新しいコピーをhfsdebugで調べると、断片化は少なくなっているか、または解消されているだろう。
（この操作をやれと勧めてるわけではないよ！）
もしあなたがHFS+ボリュームのデフラグをやると固く決心しているなら、
自分専用のデフラグツールを自前で作るのが最適な方法だ。
Carbon File Managerなら、ボリューム上の連続領域にファイルを書き込む機能を持っている。
/*
ファイルを移動したり名前を変えたりしても、カタログノードID（CNID）は変わらない。
*/
● 結論
システムの断片化抑制機構が実にうまく働いているため、HFS+のデフラグをやる必要は全くないし、やる価値もない。
デフラグには常にリスクが伴う。停電したらどうする？ システムがクラッシュしたら？
デフラグツールにバグがあったら？ 途中でうっかり再起動してしまったら？
場合によっては、あなたはデフラグによってさらに悪い状況に陥ってしまうのだ。
デフラグツールはホットスペースをいじるべきではない。勝手にいじるとパフォーマンスが落ちる！
*/
● デフラグをやる人は哀れ
見てきた通り、10.3.X上のHFS+ボリュームは断片化がよく抑えられており、
デフラグツールのような高級治療薬が必要になるほど悪化するとは考えられない。
hfsdebugはボリュームの断片化ファイルを全表示し、各ファイルのエクステント数を見ることができる。
多くの要因（ファイルサイズ、ボリュームの空き領域etc）があるが、もしあなたが激しく断片化したフォークを
単純に移動、コピーして新しい名前をつけるとする。
その新しいコピーをhfsdebugで調べると、断片化は少なくなっているか、または解消されているだろう。
（この操作をやれと勧めてるわけではないよ！）
もしあなたがHFS+ボリュームのデフラグをやると固く決心しているなら、
自分専用のデフラグツールを自前で作るのが最適な方法だ。
Carbon File Managerなら、ボリューム上の連続領域にファイルを書き込む機能を持っている。
/*
ファイルを移動したり名前を変えたりしても、カタログノードID（CNID）は変わらない。
*/
● 結論
システムの断片化抑制機構が実にうまく働いているため、HFS+のデフラグをやる必要は全くないし、やる価値もない。
デフラグには常にリスクが伴う。停電したらどうする？ システムがクラッシュしたら？
デフラグツールにバグがあったら？ 途中でうっかり再起動してしまったら？
場合によっては、あなたはデフラグによってさらに悪い状況に陥ってしまうのだ。