さてさて、これまで述べてきたような知識をもとにして、 いよいよ実際のレイアウトについて述べることにしましょう。 以下の方法は筆者が 3 台の古いSCSI ディスクを使って、 いろいろな可能性を試しながら作り出してきたものです。
付録の表は、このマッピングの過程を簡単にするためにデザインされました。 最適化のプロセスをすすめていく作業の助けになるでしょうし、 システムを改善する時にも有用な記録となってくれるでしょう。 いくつかの例も同時に載せてあります。
必要な機能を決め、 別々のパーティションに分けるファイルシステムのリストを作ります。 それを必要とされる速度の順に並べ、 それぞれのパーティションに割り当てる容量を決めます。
付録 A の表が役に立つでしょう。 この表には論理ディレクトリが順に並べてあり、 マウントポイントに関するメモや別の OS に使う領域を書き込む部分が確保してあります。 この表は速度順には並んでいません。 代わりに必要とされる速度を 'o' の数で示してあります。
RAID を利用するのでしたら、どのディスクを使って、 どのパーティションを RAID 化するかを決めておきましょう。 RAID には色々な種類があり、 様々な速度／信頼性が選択できることを頭に入れておきましょう。
(以下では話を簡単にするために、 同じ SCSI ディスクがいくつかある場合を考えましょう。 RAID は使わないものとします)
次の段階では、パーティションをディスクに割り当てていきます。 これから述べるアルゴリズムのポイントは、 並列性を最大限確保してバスの容量をめいっぱい使うようにすることです。 例として、ドライブ A B C に対してパーティション 987654321 を割り当てることを考えます。 9 が最も高速性が要求されるパーティションです。 一つめのドライブから出発して、 パーティションのラインを「くねらせて」いきます。 こんな感じです。
A : 9 4 3
B : 8 5 2
C : 7 6 1
これで高速性の要求量に対する重みが、 どのドライブでも同じくらいになります。
付録 B につけた表を使って、 どのドライブのどのパーティションを用いるかを選んでください。 並列性が最高になるようにしましょう。
持っているドライブの速度の特性と、 それぞれのディレクトリを適当な列に記入してください。 ディレクトリやパーティション、ドライブは何回か入れ替えたくなるでしょうから、 表はその分用意しておきましょう。
以上ができたら、 それぞれのドライブでパーティションの番号づけを行いましょう。
付録 C の表を用いて、 パーティションの順番を決めてください。 トラックの特性が生かされるようにしましょう。 全部できたら、表をパーティション番号の昇順に並べ替えましょう。 これらの番号を付録 A や B の表に書き戻してください。
fdisk や cfdisk などのパーティション分割プログラムを使うときや
インストール作業を行うときに、これらの表を参考にすると良いでしょう。
上の手続きの後、通常いくつかのパーティションは入れ替える必要があります。 大きさを合わせたり、速度、信頼性、 その他ファイルシステム特有の問題などを解決するためです。 しかしそれでもここで与えた方法は ドライブとパーティションを最適に設定するための良い出発点になります (と筆者は信じています)。 何が必要とされるかについてを色々と考えてきたわけですが、 本当のところは実際にシステムを運用してみないと解らないでしょう。 実際に運用を始めたのち、 パーティションの切り直しが必要とされるような時期が いつかはやって来ると思っていたほうが良いでしょう。
例えば上で用いた 3 台のドライブのうち、 一つが他に比べて非常に遅いような場合には、 最適な配置は以下のようになるでしょう。
A : 9 6 5
B : 8 7 4
C : 3 2 1
総合的なスピードが似たようなドライブでも、 ファイルのサイズやアクセスの頻度などによって相性の良い悪いがあるものです。 たとえばバイナリの置かれているディレクトリは コマンドキューが機能するようなアクセスの速いドライブに向いていますし、 ライブラリのディレクトリには転送速度が大きいドライブが良いでしょう。 後者に対しては IDE ディスクのコストパフォーマンスが高いかもしれません。
タスクを実行するときに、ドライブ利用の競合が起こらないようにしましょう。
たとえば /usr/local/bin にアクセスした直後に
/usr/local/lib のファイルが必要になるような場合、
これらのディレクトリを別々のドライブに置いておけば、シークや読み込み、
キャッシュなどの並列化・高速化が期待できるでしょう。
並列動作が期待できる場合には、先に述べたような最適化がなされている場合よりも
優れた性能が得られることは充分ありえます。
よく行われるタスクでどのパーティションが同時に使われるかを考え、
それらを別々のディスクに置くようにしましょう。
いまの内容をもう少し詳しく述べましょう。 以下にタスク状況の解析例をいくつか示します。
エディタやワードプロセッサ、スプレッドシートなどが典型的な例です。 CPU の負荷もディスクの負荷もそれほど高くありません。 しかし、大量のユーザを抱えているサーバなどを管理している場合には、 これらのソフトのオートセーブ機能についてしっかり認識しておきましょう。 この機能はホームディレクトリに余分なトラフィックを生じることになります。 ユーザのホームディレクトリをいくつかのドライブに分散させておけば 負荷の集中を減らすことができます。
ニュースリーダもホームディレクトリへのオートセーブを行なうので、 サービスプロバイダならばホームディレクトリを 別のドライブに分ける方が良いでしょう。
ニューススプールはディレクトリ構造がとても深くなり、
小さなファイルがとてもたくさん置かれます。
ニューススプールパーティションが失われても
大部分の人には大きな問題ではないでしょうから、
小さなディスクをたくさん集めて RAID 0 の構成にし、
シーク動作をたくさんのスピンドルに分散させると良いかもしれません。
また INN ニュースサーバのマニュアルや FAQ で推奨されていることですが、
大きなニュースサイトではニューススプールと .overview
ファイルを別のドライブに置いておくのが良いそうです。
INN optimising under Tru64 UNIX にある記述も、Linux ユーザを含む多くの読者に当てはまるでしょう。
データベースアプリケーションはドライブの容量と速度を両方とも必要とします。 詳細はもちろんアプリケーションによります。 ドキュメントを読むときにディスクの必要量に注意しておきましょう。 性能や信頼性を高めるためには RAID を導入するのも良いでしょう。
メールの送受信にはホームディレクトリと 到着用／発信用のスプールが使われることになります。 可能ならばホームディレクトリとスプールは 別のドライブに分けておくべきでしょう。メールサーバ (メールハブ) では、 到着用と発信用のスプールも別のドライブに分けると良いかもしれません。
もしあなたが ISP やメジャーなメールハブマシンを管理しているとしたら、 メールを失うのはもう最悪です。 メールスプールを RAID 化すること、 頻繁にバックアップを取ることを考えましょう。
たくさんのディレクトリが必要になります。コンパイラのバイナリやライブラリ、
インクルードファイル、さらにはソースやプロジェクトファイルなどなど。
許す限り別々のドライブに分けておきましょう。
小さなシステムでは /usr/src とプロジェクトファイルをホームディ
レクトリと一緒のドライブに入れてしまっても良いかもしれません。
WWW は人気が増す一方ですね。多くのブラウザではローカルなキャッシュを用 いており、これらはかなりの大きさになることがあります。 ローカルキャッシュは以前に読んだことのあるページを再ロードしたり、 直前のページに戻ったりするときに用いられますので、 この領域の速度はとても重要です。 しかしちゃんと設定されたプロキシサーバを経由している場合なら、 各ユーザ、各セッションにつき数 MB 程度あれば充分でしょう。 ホームディレクトリ や WWW の節も参考にしてください。
先に述べた
落とし穴
を避ける方法としては以下のようなものがあります。
スワップや /tmp, /var/tmp のように
比較的サイズが分かっているようなディレクトリにだけ
それぞれパーティションをあてがい、
他のものは残ったパーティションにシンボリックリンクを使って割り振る方法です。
例を示しましょう。遅いディスクと速いディスクがあり、
この中に一揃いのシステムを詰め込むことを考えます。
スワップと /tmp は速いディスクに置き、
/home と /root は遅いディスクへ置きます。
この作業の後に残ったディレクトリを仮に /a/slow,
/a/fast, /b/slow, /b/fast としましょう。
そして各ドライブの残ったパーティションに対して
これらのディレクトリを割り振ることを考えます。
/a と /b をそれぞれのドライブにあてがってしまうと、
サブディレクトリに同じ性能が与えられてしまいます。
4 つのディレクトリをそれぞれ別のパーティションに分けると、
今度は容量に対する柔軟性が失われてしてしまいます。
より良い解法はこれら 4 つのディレクトリを それぞれに適したドライブのディレクトリに対する シンボリックリンクとすることです。
具体的には以下のようにします。ここで
/mnt.fastdisk に速いディスクの残りパーティションを、
/mnt.slowdisk に遅いデスクの残りパーティションを
マウントしているものと考えてください。
/a/fast は /mnt.fastdisk/a/fast または /mnt.fastdisk/a.fast へリンク
/a/slow は /mnt.slowdisk/a/slow または /mnt.slowdisk/a.slow へリンク
/b/fast は /mnt.fastdisk/b/fast または /mnt.fastdisk/b.fast へリンク
/b/slow は /mnt.slowdisk/b/slow または /mnt.slowdisk/b.slow へリンク
こうすればスピードが必要なディレクトリは速いディレクトリへおくことができ、 しかもパーティションを 4 つに分割する必要もなくなります。 リンク先として右側のような表現を利用すれば ファイルシステムの無駄な階層化を防ぐことができ、 ディレクトリ構造が見やすくなるでしょう。
この方法の欠点はごちゃごちゃしすぎているため、 初期段階での計画やセットアップには向かないことです。 またシステムのインストール前に すべてのマウントポイントとパーティションを決めておかなければならないことも 問題かもしれません。
重要: /usr パーティションは直接 root に
マウントすべきで、上記のような間接リンクにすべきではありません。
なぜなら、ずうっと根元に戻るようなリンクが、
/usr の、特に X11 で頻繁に用いられており、
これらは /usr 以下から root に戻って、
/etc ディレクトリに戻ったりするからです。