Linux は開発のごく初期からマルチタスクで、そこではたくさんの プログラムが相互作用しながら共存しています。したがって ファイル構造をみんなが納得できるように保ち、システムが必要な データはそれと分かる場所に配置することが大切です。歴史的には 異なった規格がとてもたくさん存在していたため、混乱の原因となりました。 それらの互換性を取るためにシンボリックリンクが多用され、 さらに混乱を引き起こしてファイル構造をまるで迷路のように してしまったのです。
幸いなことに Linux の場合には、早いうちに File Systems Standard (FSSTND) という規格が合意され、今日の Linux ディストリビューション のほとんどで用いられるようになりました。
その後この後継規格として、 Linux 以外の OS でも用いることのできるようなものを策定することになりました。 これは Filesystem Hierarchy Standard (FHS) と呼ばれ、 現在は version 2.1 です。この規格はまだ開発も継続中ですが、 そのうち各ディストリビューションに採用されることでしょう。
自前の構造を作ってしまうことはあまりお薦めしません。 FHS には多くの考えが盛り込まれており、多くのソフトウェア パッケージがこの規格に準拠してきているからです。 FHS home page から、より多くの情報を読んでみると良いでしょう。
この HOWTO は FSSTND に準拠しようと努力しています。 FHS 向けのディストリビューションが出てきたら、 FHS に準拠したものにする予定です。
FSSTND 中の様々な構成要素に対しては、
それぞれ異なった速度・信頼性・容量が必要になります。
例えばルートパーティションを失っても、
痛手ではありますが修復は比較的簡単です。
一方 /var/spool/mail を失うのは非常にまずいでしょう。
ここではいくつかの主要なディレクトリについて、
それぞれの特徴と要求される性能とを簡単にまとめてあります。
この部分は一般的な話であることを承知しておいてください。
実行バイナリが etc や lib ディレクトリに置かれたり、
ライブラリファイルが
bin ディレクトリに置かれたりすることなども実際にはあります。
最速のものを。しかしスワップに頼りすぎているような場合は RAM を買い足すことを考えた方が良いでしょう。 ただし古い Pentium PC マザーボードの多くでは、 128 MB 以上の RAM にはキャッシュが効かないかも知れないことに注意してください。
考え方は RAM の場合と同じです。簡単な計算法をお教えしましょう。 紅茶の入れ方と一緒です。マシンに 16 MB、各ユーザに 2 MB ずつ。 最小のカーネルは 1 MB でもギリギリ走ります。 普通の仕事や軽めのアプリケーションには 4 MB、X11 や gcc には 8 MB 用意しましょう。 16 MB あれば快適でしょう。 (著者は濃い目の紅茶を淹れることで知られています...)
スワップとして RAM の 1〜2 倍を勧める人もいます。 またどんなプログラムが動いているかによって スワップスペースの有効性が決まるという指摘もあります。 4BSD の場合に使われる見積もり方法は Linux の場合にはあまり適当ではありません。 Linux は core の中にページングのための領域を確保しないからです。
もっと完全なやり方は、スワップスペースと RAM の和を あなたの用いるワーキングセットの総計と考えることです。 自分が必要とするメモリ空間の最大量を知っているなら、 そこから物理 RAM の量をひいてスワップの量とすれば良いわけです。
スワップのサイズを決めるときには、気前良くたくさん割り当てた方が 良いかもしれません。これには理由があります。メモリリークです。 お作法を守らないプログラムでは、 自分に割り当てたメモリを解放しないものがあります。 これを「メモリリークがある」と表現します。 このようなプログラムに割り当てられたメモリは、 この悪党プログラムが終了したあとでも解放されず、 したがってメモリ消費の原因になります。 物理 RAM とスワップスペースがすべて使われてしまえば、 解決法はただ一つ、再起動してやり直すしかありません。 ありがたいことにこのようなプログラムはそう多くはありませんが、 でもいつかそんなプログラムに出くわしたときには、 余分にとっておいたスワップスペースのおかげで 再起動の間の時間が長く取れるようになっていることがわかるでしょう。
使っているプログラムによっても話は変わってきます。 画像処理ソフトのように大きな実行領域を必要とするプログラムでは、 RAM に巨大なデータ構造がロードされ、 ディスク上でデータが扱われることはあまりありません。 このようなデータ負荷および CPU 負荷が高いプログラムでは、 必要な RAM が無いとスワップの嵐に見舞われることになります。
また、自分自身の実行イメージ (の一部) を RAM にロックしてしまうプログラムもあります (ページロックと呼ばれます)。 セキュリティの問題から データをスワップデバイスへコピーできないようなプログラムや、 あるいは高速処理が必要なリアルタイム指向のプログラムなどが該当します。 ページロックが行われるとスワップ可能なメモリ量が減りますから、 予想より早い段階でスワップが起こることになります。
man 8 mkswap によれば、スワップパーティションひとつあたりについて、
32 ビットマシンなら 128 MB にちょっと足りないくらい、
また 64 ビットマシンなら
256 MB にちょっと足りないくらいの大きさを割り当てることができます。
しかしカーネル 2.2.0 以降では、この制限は 2 GB に変更されました。 man ページもこの変更を受けて更新されました。
中程度。障害が起こったときにはすぐわかりますし、 それによって失うものもたいしたことはないでしょう。 セーブはこまめにしてるでしょ？
Linux では複数のデバイスにまたがるかたちでスワップを配置できます。
この機能は使ってみると意外と便利です。詳しい内容については
"man 8 swapon"
を見てください。ただしソフトウェア版 RAID を複数のデバイスに用いて、
それをスワップにするのはオーバーヘッドのほうが大きいでしょう。
この場合の /etc/fstab/ ファイルの内容は以下のようになるでしょう。
/dev/sda1 swap swap pri=1 0 0
/dev/sdc1 swap swap pri=1 0 0
fstab は書式に非常に厳しいので、
必ず man ページをしっかり読むようにしてください。
上の行をカット & ペーストするだけじゃ駄目ですからね。
RAM ディスクをスワップなどのファイルシステムに使っている人がいるようです。 しかし非常に特殊な場合を除けば、この方法はあまり得にはならないでしょう。 キャッシュやバッファに使えるメモリが減少してしまうからです。
ひとつだけ例外があります。 世の中には設計の悪いマザーボードがたくさんあって、 アドレスできる RAM のすべてをキャッシュできない場合があります。 古いマザーボードの多くでは、 メモリは 128 MB 使えてもキャッシュはその内の 64 MB にしか効かないのです。 このような場合には、 上位の (キャッシュされない) 64 MB の RAM をラムディスクにして、 スワップ領域や一時記憶領域にした方が良い場合があります。
/tmp と /var/tmp)
高速のものを。別のディスクやパーティションにおけば、フラグメンテーショ ンを減らせます。もっとも ext2fs はフラグメンテーションをうまく扱うこと ができますので、それほど気にしなくても良いかもしれません。
訳注: フラグメンテーション (fragmentation): 頻繁にアクセスされるディスク領域においては、 ファイルの保存領域が断片化しやすくなります。 この現象を一般にフラグメンテーションと呼び、 ファイルアクセス性能の低下の一因となります。
難しいです。小さなシステムなら数 MB でも足りるでしょう。
しかしこれらのディレクトリは、
他のユーザや quota の制限から
ファイルを隠すことのできる場所として知られているので、
マルチユーザの大きなマシンでは際限無く大きくなることがあります。
以下は筆者のお勧めです: 家で使う場合は、小さなマシンなら 8 MB、
大きめの場合 32 MB。小さなサーバでは 128 MB、大きなサーバで最大 500 MB。
なお筆者が仕事で使っているマシンでは
1100 名のユーザに対し /tmp ディレクトリを 300 MB とっています。
これらのディレクトリには目を配っておき、
隠し属性のファイルや古いファイルに注意しましょう。
パーティションの切り直しが必要になるのは、
ここのディレクトリが原因であることが多いようです。
低くて良いです。これらの領域が壊れていたり一杯だったりしても、 大抵のプログラムは礼儀正しくできていますので、 警告を発するか停止してくれるでしょう。 もちろん偶発的なファイルエラーは深刻な問題ですが、 これはどんなファイル領域でも同じことです。
ほとんどは小さなファイルですが、膨大な数になります。
普通のプログラムは使用した一時ファイルを消しますが、
割り込みがあったりすると残ってしまうこともあります。
多くの配布パッケージでは
tmp ファイルを起動時に消去するような設定がなされています。
自分のシステムではどうなっているか確認しておくと良いでしょう。
FSSTND では /tmp を
RAM ディスクに置くと良いといった記述があります。
しかしスワップのところで述べたのと同じ理由で、
これはおすすめできません。また、これも先に述べましたが、
フラッシュ RAM のドライブをこれらのディレクトリに割り当てるのもやめましょう。
古いシステムでは /usr/tmp があるかもしれませんが、
これはもう推奨されていません。ただし歴史的な理由から、
他の tmp 領域へのシンボリックリンクとして残されていることがあるようです。
(* これで何行かな？いま自宅ですが、ノド乾いたなあ。*)
/var/spool/news と /var/spool/mail)
特にニュースサーバ用途には速いものを。 ニュースの配信や消去はディスクを酷使しますので、 速いディスクから得られるメリットは大きいでしょう。 プリントスプールは遅くても良いです。 ニュースには RAID 0 の使用も考えましょう。
ニュース／メールサーバの場合はできる限り大きなものを。
シングルユーザのシステムで常時読んでいるような場合は数 MB で十分でしょう。
ただしトラフィックの大きいメーリングリストに参加している人が
休暇を取るような場合には、
これでは足りないかも知れません。私が仕事で使っているマシンでは
/var/spool 全体に 100 MB を割り当てています。
メールの場合は非常に高い必要があります。ニュースは普通、プリントスプー ルは低くて良いでしょう。メールが重要なら (普通はそうでしょ？) 信頼性を高めるために RAID の導入を考えましょう。
サイズ数 KB の大きさのファイルが非常にたくさん置かれます。 逆にプリントスプールの場合は、 数は少ないですが各ファイルはかなり大きなものになります。
ニュース関連の文書では、
.overview ファイルをすべてまとめて、
ニュースファイルとは別のドライブに置くことを勧めているようです。
より詳しくは news に関する FAQ をチェックしてください。
この大きさはニューススプールの総量の 3〜10 パーセントくらいになります。
/home)
普通です。大抵のプログラムは一時的な保存場所に
/tmp を用いますが、
ニュースリーダのように
ホームディレクトリのファイルを頻繁に更新するプログラムもあります。
小さなシステムでは問題にならないでしょうが、
大きなマルチユーザシステムだと気になることがあるかもしれません。
難しいです。ユーザがディスク容量に対して対価を支払うようなシステムでは、 これはお金の問題になるでしょう。 Nyx.net はメール、ニュース、WWW といったインターネットサービスを 無料で提供している大きなシステムですが、 ユーザ一人あたり最大 300 KB、推奨 100 KB という制限でうまく稼動しています。 商用プロバイダの通常の契約では 5 MB 程度を利用できる場合が多いようです。
本を書いたりデザインワークをしているような場合には、 必要な容量はフーセンのようにあっという間に膨らむでしょう。
流動的です。シングルユーザのマシンで
/home が失われるのも困ったことではありますが、
2000 人のユーザから
「ホームディレクトリが無くなった」という電話を受けるのとは
「困った」の度合が全然異なるでしょう。
彼らユーザの中には生活の糧となる情報をここに置いている人もいるかもしれません。
もちろん定期的なバックアップはしてますよね？
同じく流動的です。ユーザ一人当たりの最小のセットアップでは、 ファイルが数 10 個、サイズは 0.5〜5 KB 程度になるでしょう。 プロジェクト関連のファイルはずっとずっと大きくなるでしょう。
スピードと信頼性を求めるなら RAID を考慮すべきです。 さらなる高速性や信頼性が必要なら、 他の OS やプラットホーム (耐故障システムなど) を考えるべきでしょう。
多くの Web ブラウザは ブラウジングを高速化するためにローカルなキャッシュを利用します。 このキャッシュはかなりたくさんの容量を必要としますし、 またディスクに対するアクセス要求が頻繁になります。 これによって生じる性能低下を避ける方法はいくつかあります。 具体的な情報に関しては ホームディレクトリ や WWW の節を参考にしてください。
ユーザーは /home に割り当てられた自分のスペースを
簡単に使い切ってしまうものです。
Linux の Quota サブシステムはユーザー ID ひとつあたりに割り当てるブロック数と
inode 数をファイルシステム単位で制限できます。
設定の詳細は Albert M.C. Tam bertie (at) scn.org
の書いた
Linux Quota mini-HOWTO
を見てください。
訳注: Quota mini-HOWTO の日本語訳 は JF にあります。また最新の quota システムのマニュアルの翻訳が JM Project でなされています。
/usr/bin と /usr/local/bin)
遅くて良いです。プログラムはデマンドロードされるので、 むしろデータの方が大きいことの方が多いです。 したがって速度は重要ではありません。 CD-ROM 上の live ファイルシステムの成功が証拠です。
訳注: live ファイルシステムとは CD-ROM 上にルートファイルシステムを置いて直接ブート可能にしたものです。 詳細については http://www.pdc.com/wp29.htm などをご覧ください。
上限は遥か天空の彼方ですが、 大抵のシステムなら 200 MB あれば必要なものの大部分は入るでしょう。 ソフト開発を行うホストや多目的サーバなどの大きなシステムでは インストール時に 500 MB、 将来のためにさらに 500 MB の領域を確保しておくと良いでしょう。
低くて良いでしょう。 このパーティションは普通ルートパーティションにマウントされるでしょうが、 ほんとうに大事なものはルートに入っているでしょうから。 しかしバイナリをすべて失うのは痛いことは痛いですね...
いろいろな大きさのファイルがあるでしょうが、だいたい 10〜100 KB くらいのものが多いでしょう。
/usr/lib と /usr/local/lib)
普通です。ここにはオブジェクトファイルからフォントに至るまで、 頻繁にロードされる図体のでかい (しかも近年さらに拡大傾向にある) データが置かれます。 これらは一度に全体がロードされるので、 ここに速いディスクを使うのはそれなりの価値があります。
流動的です。
例えばワードプロセッサなどが
大量のフォントファイルを保存するような場合もあります。
この文書に対してフィードバックをくれた方の中には、
種々の lib ディレクトリに 70 MB 使っている人もいました。
Debian 1.2 をほぼすべてインストールすると、だいたい 250 MB になります。
これを実際の上限と考えておくと良いでしょう。
ディスク食いの最たるものとしては、
GCC, Emacs, TeX/LaTeX, X11, perl などがあります。
低くて良いです。理由は バイナリ の節で述べたものと同じです。
普通は大きく、 1 MB のオーダーのものが多いでしょう。
歴史的な理由から、いくつかの実行プログラムファイルは lib 領域に置かれ
ています。例えば GCC はいくつかの非常に大きなバイナリファイルを
/usr/lib/gcc/lib 以下のディレクトリに置いています。
非常に遅くてかまいません。 ブートはそんなにたくさん行われるものではないですし、 カーネルのロードもシステムの立ち上げにかかる時間のほんの一部でしかありません。
極めて小さくて良いでしょう。完全なイメージにいくらか追加をしても 1 枚のフロッピーに収まるのですから、 5 MB あれば十分過ぎるでしょう。
高い必要があります。以下の Root の部分を参照。
Boot パーティションについて最も気をつけなければいけないことは、 これは多くのシステムでは 1023 シリンダ以下の部分に置かなければならない、 ということです。これは Linux では回避できない BIOS の制限なのです。
上記は最近の IDE システムには必ずしも 当てはまりません。また SCSI ディスクにも当てはまりません。 より詳しい情報は最新の Large Disk HOWTO を参照してください。
1023 セクタの制限を受けない新しいブートローダが、 最近開発されました。詳細は nuni に関する記事 を見てください。
かなり遅くても大丈夫です。 ほんとうに必要最小限のものしかここにはありませんし、 大部分は起動時にしか実行されません。
比較的小さくて良いでしょう。 しかしシステム修復に必要なファイルやユーティリティ、 バージョンの違ういくつかのカーネルなどを ルートパーティションに置いておくのも良いアイデアだと思います。 この文書に対するフィードバックをまとめると、 20 MB あれば十分なようです。
高くなければなりません。このブートパーティションが壊れると、 悲しい思いをする人が多いでしょう。 また復旧にも結構な時間がかかってしまいます。 もちろん練習を積めば 1 時間かそこらで復旧できるようにもなるでしょうが、 復旧の練習を積んでいる人は何か別のヘマもしている人だと私は思います。
もちろんレスキューディスクは用意してありますよね。 最初のインストールのときからアップデートしましたか？ 世の中には有用なレスキューディスクや、 ディスク作成用のツールが多く存在します。 ルートシステムのレスキューの専門家になるよりも、 これらのツールを探す方が時間を有効に使えるでしょう。
ドライブがたくさんあるのでしたら、 緊急用としてスペアのブートパーティションを 別のドライブに用意しておいても良いかもしれません。 ディスク容量は少々損しますが、セットアップにかかる時間を考えれば、 何かが壊れたときの保険としては充分価値があります。
ルートパーティションを RAID 0 のシステム上に置くのはお勧めできません。 立ち上げ動作が複雑になりますし、障害の際にも問題があります。また、 ブートパーティションに RAID を使う場合は、 レスキュー用カーネルの md 機能を忘れずに有効にしておくことです。
システムを単純化するため、
Boot と Root を同じパーティションに配置することは
ごくごく普通に行われています。
このとき LILO からブートするには、
ブートに必要なファイル
(カーネルと /boot に置かれているファイル群)
をすべてシリンダ 1023 以下の範囲に収めておくことが大事です。
異教徒と思われたくはないんですが、 読者のみなさんが迫害しているこの手のブツについても 一節を設けることにしました。 残念ながらハードウェアに付いてくる設定ツールには、 この種の OS でしか動かないものがまだ多いんです。 では行きます。
非常に遅くて良いでしょう。 これらのシステムに対して「高速だ」という評判は聞いたことがありませんから、 ここに高性能のドライブをあてがう価値はほとんどありません。 マルチタスクでもマルチスレッドでもありませんから、 SCSI ドライブのコマンドキューの機能を有利に働かせることもできません。 古い IDE のディスクがあればそれで充分でしょう。 Win95 や NT のカーネルは一応マルチスレッドをサポートしているようですので、 理論的には高機能な SCSI デバイスを有効に使える可能性もあります。
これらの OS を作っているメーカには 「コードが小さい」という評判は特に無いようですから、 インストールする OS や Windows のバージョンにもよりますが、 数 10 MB 程度を用意しておく必要があるでしょう。古いバージョンの DOS や Windows なら 50 MB あればたいていのものは詰め込めるでしょう。
はは。「鎖の強さは最も弱い環で決まる」という言葉を聞いたことがありますか？ どんな古いドライブでも構わないでしょう。 ドライブが壊れる前に OS が飛んでしまいますから。 きっと誰もがこのパーティションからバックアップの重要さを学ぶでしょう。
別の言葉で言いましょうか。 「君の任務はこのパーティションを稼動させ続けることだ。 なおこのメッセージは 10 秒以内に自動的に消滅する...」
最近、これらの主張の正当性を示せと言われました。 でもちょっと待って下さい。 まず私は DOS や Windows のことを、 OS のひどいマガイモノだと言っているわけではありません。 法律的な問題も色々と考えなければなりません。 あー、このいまの 2 文の間に関係があると言うのは偏執者の戯言です。 本当ですって。 えー、では代わりに尊敬すべき読者の皆さんに いくつかのキーワードを差し上げましょう。 DOS 4.0、DOS 6.x、名もないままに消え去ったたくさんのドライブ圧縮ツール...
もちろんディスクは速いに越したことはありません。 しかし Linux のインストールに当たっては、 様々なスピードや信頼性のディスクが混在することが珍しくありません。 この文書では性能を「速い」とか「遅い」とか言っていますが、 これは粗っぽい分け方に過ぎません。これ以上細かく区別するのは難しいんです。 それでも心に止めておくと良い点はいくつかあります。
実際には「速度」というのはいくつかの要素が複雑に絡み合って決まっています。 例えば CPU 負荷、転送前のオーバーヘッド、ディスクのシーク時間、 転送速度などです。 確立した最適なチューニングというものはありません。 たいていの場合は価格が最も重要な要素になるでしょう。 CPU 負荷は IDE システム以外ではそれほど問題になりません。 IDE システムでは CPU が転送に関与しますが、 SCSI では CPU 負荷は一般に小さいです。 実際の数値に関しては SCSI についての文書を見てください。 ディスクのシーク時間は小さいほうが良く、通常数ミリ秒程度が望ましいでしょう。 SCSI のコマンドキューが使える場合には、 コマンドを重ね送りしてバスを常に有効にできるので、 シーク時間はそれほど問題にはならないでしょう。 ニューススプールのように小さなファイルを大量に含んでいるような特殊な場合には、 シーク時間は重要になるでしょう。
ここでは、二つの主要なパラメータについてもう少し述べます。
これはディスクの読み書きに際して、 ヘッドがあるトラックから別のトラックへ移動するのにかかる平均時間のことです。 このパラメータは数多くの小さなファイルを扱うような場合に重要になります。 スプール領域などが該当します。 また指定されたセクタがヘッドの位置に回転してくるまでに消費される遅れ時間も シーク時間に含まれます。この遅れはドライブの回転速度に依存し、 回転速度がドライブの主要なパラメータとみなされている理由の一つになっています。 通常用いられる値は 4500, 5400, 7200 RPM (rotation per minute: 一分あたりの回転数) です。 回転数が高いものはシークが早くなりますが、高価になります。 また 7200 RPM 動作するドライブは騒音や発熱量が大きくなりがちです。 この事は巨大なディスクアレイやディスクファームを作るときには 気に留めておく必要があるでしょう。 つい最近には 10000 RPM で動作するドライブも市場に出てきました。 この製品では冷却条件が特に厳しくなっており、 エアーフローに関する条件が動作保証に必要になりました。
通常 MB/s という単位で記されます。 このパラメータは大きなファイルを扱う場合に重要になります。 ライブラリのファイルや、辞書・画像ファイルなどがこれに当たります。 回転数の高いドライブでは転送速度も回転速度に比例して大きくなります (セクタ密度が一定の場合)。
以上からわかるように、ドライブの性能表を注意深く読むことは重要です。 またスペック中の最大転送速度は、 オンボードキャッシュからの転送速度で与えられていることが多く、 必ずしもディスクから直接転送するときの速度ではないことに注意してください。 電力と発熱 の節も見ておくようにしてください。
わざわざ低い信頼性のディスクを欲しがる人もいないでしょうが、 古いディスクは信頼性が低いと思っておくほうが良いでしょう。 ところで RAID の用途には、 いろいろな種類のディスクを混ぜて使うのが良いとされています (関連する文書を見てください)。 そうしておけば、ディスクの同時クラッシュが避けやすくなるからです。
今のところ、ファイルシステム全体が故障したという報告は 私は一つしか聞いたことがありません。 しかし不安定なハードウェアは数多くの障害の原因になるようです。
最近では随分ディスクは安くなりましたが、 人々はまだドライブの中身の重要性を過小評価しているようです。 より高い信頼性が必要なら、 古いドライブは置き換えて、古い方はスペアとして保存しておきましょう。 ドライブが何年にもわたって連続運転を続けることは 特に珍しくはありませんが、 結局最後にドライブを壊してしまうのは電源の on off であることが多いようです。
ファイルの大きさの平均値は、 ドライブのパラメータを選択・決定するときに重要な意味を持ちます。 たくさんの小さなファイルを扱うときはシーク時間が、 大きなファイルを扱うときは転送速度が重要になります。 多数の小さなファイルを扱う場合は SCSI のコマンドキュ−が有利に働きますが、 転送速度に関しては安い IDE のディスクも SCSI にそれほどひけをとりません。