This is an archive of past FreeBSD releases; it's part of the FreeBSD Documentation Archive.
ファイルシステムのレイアウトを disklabel(8) や sysinstall(8) で行う際, ハードディスクの外周部は 内周部よりもデータ転送が速いということを覚えておくことが大事です. これに従えば, ルートやスワップのような小さくて激しくアクセスされるファイルシステムを外周付近に, /usr のようなより大きなパーティションはその内側に配置すべきでしょう. そうするなら, パーティションを作成する際には, ルート, スワップ, /var, /usr のような順で作ってゆくのがよいでしょう.
/var パーティションのサイズは あなたが計算機をどのように使おうとしているかを反映します. /var は主としてメールボックスやプリントスプール, ログファイルの保持に使われます. 特にメールボックスとログファイルは, あなたのシステムのユーザ数やログの保持期間に依存して予期し得ぬサイズにまで成長します. もしあなたがメールサーバを運用する予定なら /var パーティションはギガバイト以上のものがよいでしょう. さらに, /var/tmp は追加したくなるかもしれない パッケージを収められるだけの大きさが必要です.
/usr パーティションはシステムを サポートするのに必要なファイル群と, ports(7) 階層からインストールされたファイル群を収める /usr/local と呼ばれるサブディレクトリを その中に含みます. ports をまったく使わずシステムのソース (/usr/src) も不要だというのであれば, 1 ギガバイトの /usr パーティションだけで充分です. しかし, ports (特にウィンドウマネージャや Linux エミュレーションを使うバイナリ) を少なからずインストールするのであれば 少なくとも /usr に 2 ギガバイトを薦め, システムのソースも置こうというなら 3 ギガバイトの /usr を推奨します. このパーティションで必要になる量を過小評価してはいけません. それは驚く程に蔓延るものなのです!
パーティションのサイズを考える時, 必要量にシステムの成長分を見込んでおいてください. 別のパーティションには潤沢にスペースが余っているのに, あるパーティションでスペースが足らないままというのは フラストレーションがたまるものです.
Note: sysinstall(8) の Auto-defaults パーティションサイズを使ったことのある人なら, そのルートや /var パーティションが 小さすぎることを知っているでしょう. 賢明かつ気前よくパーティションを切ってください.
経験からスワップサイズはメインメモリの 2 倍というのが一般的です. つまり, 計算機のメモリが 128 メガバイトならばスワップファイルは 256 メガバイトになります. メモリの少ないシステムでは, もっとスワップを増した方が性能がよくなります. 256 メガバイト未満のスワップでシステムを設計することはお薦めできません. またスワップサイズを決める時に, 将来のメモリ増設のことも考えておくべきです. カーネルの VM (訳註: virtual memory(仮想メモリ)) ページングアルゴリズムはスワップパーティションがメインメモリの 2 倍以上存在するときに最も性能を発揮するように設計されています. スワップが少なすぎる設定は, あなたが後にメモリを増設したときに問題を起すばかりではなく, VM ページスキャニングのコードを能率を落します.
最後に, 複数の SCSI ディスク (や異なるコントローラで操作される複数の IDE ディスク) を持つ大規模なシステムでは, それぞれのドライブ (4 台まで) にスワップを設定することを強く推奨します. 各ドライブのスワップパーティションはほぼ同一サイズであるべきです. カーネルは任意のサイズを扱うことができますが, 内部のデータ構造は最大のスワップパーティションの 4 倍に調節されます. スワップパーティションをほぼ同一のサイズにしておくことで カーネルはスワップスペースを最適なかたちで ディスクをまたいでストライブさせることができます. こだわりすぎる必要はありません. スワップスペースは UNIX のつつましい美点です. あなたが通常スワップをたくさん使わないとしても, プログラムが暴走してもリブートさせられる前に回復する時間を多く得られます.
何故パーティション化してしまうのでしょう? 何故巨大な root パーティション一発では駄目なのでしょう? そうすれば容量が溢れるかもと心配しなくてもすむのに!
いくつかの理由からそれはよいアイデアとは言えません. まず各パーティションはアクセスの特徴がそれぞれ異なっていて, 分離しておくことでそれぞれの特徴に応じたチューンができるようになるからです. root パーティションや /usr パーティションはほとんどが読み出しでわずかな書き込みがあるだけですが /var や /var/tmp パーティションでは大量の読み書きが発生します.
システムを適切にパーティション化することで 小さいが書き込みの激しいパーティションによって引き起こされる フラグメント化を読み出し専門のパーティションにまで波及させずにすみます. また書き込みの激しいパーティションをディスクの周辺部に配置することで, たとえばパーティションテーブル内で大きなパーティションの後のかわりに前に配置することで, それが最も必要とされているパーティションの I/O パフォーマンスを増大させることができます. 大きなパーティション内の I/O パフォーマンスもまた必要とされているでしょうが, それらは大きすぎてディスク周辺部へ移動させてやったとしても /var を周辺部に移動させることによって大きな効果が得られたのとは対照的に 意味のあるパフォーマンスの増加は見込めないでしょう. 基本的にリードオンリーな root パーティションを小さくまとめておくことで 不幸なクラッシュを生き延びるチャンスが増大します.