まず自分の置かれている立場と、何がしたいのかということから始めましょう。 家庭のシステムは既にあるハードウェアにインストールされることが多いでしょ う。新しく Linux ユーザになった人は、その既存のハードウェアから最高の パフォーマンスを引き出したいと思うでしょう。逆にインターネットプロバイ ダのような特定の目的のために新たなシステムをセットアップする場合は、何 が必要でそのために何を買わなければならないかを考える必要があります。こ の文書では、この両極をカバーしたいと思っています。
様々な目的に応じて、ファイルシステムのドライブへの配置も異なってくるで
しょう。例えばマルチユーザで使うような大きなマシンなどでは
/home
を独立したディスクに分離するのが良いでしょう。
性能を上げるには、一般にできるだけたくさんのものを別々のディスクに分け るのが有利です。しかし一つの SCSI バスにつなぐことのできるデバイスの数 は限られていますし、コストの問題も絡んでくるでしょう。またパーティショ ンやディスクの数が増えるにつれて管理が面倒になるという点も重要です。
FSSTND 中の様々な構成要素に対しては、それぞれ異なった速度や信頼性、サ
イズが必要になります。例えばルートパーティションを失っても、痛手ではあり
ますが比較的修復は容易です。 /var/spool/mail
を失うのはまた違っ
た意味があるでしょう。ここではいくつかの重要なディレクトリについて、そ
れぞれの特徴と要求される性能とを簡単にまとめてあります。この部分は一般
的な話であることを承知しておいてください。実行バイナリが etc
や
lib
ディレクトリに置かれたり、ライブラリファイルが bin
ディ
レクトリにあったりすることも実際にはあります。
最速のものを。しかしスワップに頼りすぎているような場合は RAM を買い足 すことを考えた方が良いでしょう。
RAM の場合と似ています。簡単な計算法をお教えしましょう。紅茶の入れ方と 一緒です。マシンに 16 MB、各ユーザに 2 MB ずつ。最小のカーネルは 1 MB でもギ リギリ走ります。普通の仕事や軽めのアプリケーションには 4 MB、X11 や gcc には 8 MB 用意しましょう。 16 MB あれば快適でしょう。[著者は濃い目の紅茶を 淹れることで知られています...]
スワップとして RAM の 1〜2 倍を薦める人もいます。またどんなプログラム が動いているかによってスワップスペースの有効性が決まるという指摘もあり ます。 4BSD の場合に使われる見積もり方法は Linux の場合にはあまり適当で はありません。Linux は core の中にページングのための領域を確保しないか らです。
話は使っているプログラムによっても変わってきます。有限要素法のように大 きな実行領域を必要とするようなプログラムでは RAM に巨大なデータ構造が ロードされ、ディスク上でデータが扱われることはあまりありません。このよ うなデータ負荷および CPU 負荷が高いプログラムでは、必要な RAM が無いと スワップの嵐に見舞われることになります。
また、自分自身の実行イメージ(の一部)を RAM にロックしてしまうプログ ラムもあります(ページロックと呼ばれます)。セキュリティの問題からデー タをスワップデバイスへコピーできないようなプログラムや、あるいは高速処 理が必要なリアルタイム指向のプログラムなどが該当します。ページロックが 行われるとスワップ可能なメモリ量が減りますから、予想より早い段階でスワッ プが起こることになります。
中程度。障害が起こったときにはすぐわかりますし、それによって失うものも たいしたことはないでしょう。セーブはこまめにしてるでしょ?
Linux では複数のデバイスにまたがってスワップを利用することができます。
この機能は使ってみると意外と便利です。詳しい内容については
"man 8 swapon
"
を見て下さい。ただしソフトウェア版 RAID を複数のデバイスに用いて、それ
をスワップにするのはオーバーヘッドのほうが大きいでしょう。
この場合の fstab
ファイルの内容は以下のようになるでしょう。
/dev/sda1 swap swap pri=1 0 0
/dev/sdc1 swap swap pri=1 0 0
fstab
は書式に非常に厳しいので、必ず man ページを読んでから実際に
使うようにしてください。上の行をカット & ペーストするだけじゃ駄目
ですからね。
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 のドライブをこれらの
ディレクトリに割り当てるのも止めましょう。またシステムによっては再起動
の際に /tmp
領域を自動的に消去することになっているものもあり
ますので注意してください。
(* これで何行かな?いま自宅ですが、ノド乾いたなあ。*)
/var/spool/news
、/var/spool/mail
)
特にニュースサーバ用途には速いものを。ニュースの配信や消去はディスクを 酷使しますので、速いディスクから得られる利益は多いでしょう。プリントス プールは遅くても良いです。ニュースには RAID 0 の使用も考えましょう。
ニュース/メールサーバの場合はできる限り大きなものを。シングルユーザの
システムで常時読んでいるような場合は数 MB で十分でしょう。ただしトラフィッ
クの大きいメーリングリストに参加している人が休暇を取るような場合には、
これでは足りないかも知れません。私が仕事で使っ
ているマシンでは /var/spool
全体に 100 MB を割り当てています。
メールの場合は非常に高い必要があります。ニュースは普通、プリントスプー ルは低くて良いでしょう。メールが重要なら(でしょ?)信頼性を高めるため に RAID の導入を考えましょう。
数 KB の大きさのファイルが非常にたくさん置かれます。逆にプリント スプールの場合は数は少ないですがかなり大きなファイルになります。
ニュースについての文書には、全部の .overview
ファイルをニュー
スファイルとは別のドライブに置くことを薦めているものもあるようです。よ
り詳しくは news に関する FAQ をチェックして下さい。
/home
)
普通です。大抵のプログラムは一時的な保存場所に /tmp
を用いま
すが、ニュースリーダのようにホームディレクトリのファイルを頻繁に更新す
るプログラムもあります。大きなマルチユーザシステムだと気になることがあ
るかもしれません。小さなシステムでは問題にならないでしょうが。
難しいです。ユーザがディスク容量に対して対価を支払うようなシステムでは、 これはお金の問題になるでしょう。 nyx.net はメール、ニュース、WWW といったインターネットサービスを無料で提供して いる大きなシステムですが、ユーザ一人あたり最大 300 KB、推奨 100 KB とい う制限でうまく稼動しています。商用プロバイダの通常の契約では 5 MB 程度 が利用できる場合が多いようです。
本を書いたりデザインワークをしているような場合には、必要な容量はフーセ ンのようにあっという間に膨らむでしょう。
流動的です。シングルユーザのマシンで /home
が失われるのも困っ
たことですが、 2000 人のユーザから「ホームディレクトリが無くなった」と
いう電話を受けるのでは困ったどころの騒ぎではなくなります。彼らユーザの
中には生活の糧となる情報をここに置いている人もいるでしょう。もちろん定
期的なバックアップはしてますよね?
同じく流動的です。ユーザ一人当たりの最小のセットアップでは、ファイルが 数 10 個、サイズは 0.5〜5 KB 程度になるでしょう。プロ ジェクト関連のファイルはずっとずっと大きくなるでしょう。
スピードと信頼性を求めるなら RAID を考慮すべきです。さらなる高速性や信 頼性が必要なら、他の OS やプラットホーム(耐故障システムなど)を考える べきでしょう。
/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 使っている人も少数ながらい
ました。ディスク食いの最たるものとしては、 GCC、 Emacs、 TeX/LaTeX、
X11、 perl などがあります。
低くて良いです。内容については バイナリ の節を見て下さい。
普通は大きく、 100 KB のオーダーのものが多いでしょう。
歴史的な理由から、いくつかの実行プログラムファイルは lib 領域に置かれ
ています。例えば GCC はいくつかの非常に大きなバイナリファイルを
/usr/lib/gcc/lib
以下のディレクトリに置いています。
かなり遅くても大丈夫です。ほんとうに必要最小限のものしかここにはありま せんし、大部分は起動時にしか実行されません。
比較的小さくて良いでしょう。しかしシステム修復に必要なファイルやユーティ リティ、バージョンの違ういくつかのカーネルなどをルートパーティションに 置いておくのも良いアイデアだと思います。この文書に対するフィードバック をまとめると、 20 MB あれば十分なようです。
高くなければなりません。このブートパーティションが壊れると、悲しい思い をする人が多いでしょう。また復旧にも結構な時間がかかってしまいます。も ちろん練習を積めば 1 時間かそこらで復旧ができるようにもなるでしょう。 しかし復旧の練習を積んでいる人は何か別のヘマもしている人だと私は思いま す。
もちろんレスキューディスクは用意してありますよね。最初のインストールの ときからアップデートしましたか?世の中には有用なレスキューディスクや、 ディスク作成用のツールが多く存在します。ルートシステムのレスキューの専 門家になるよりも、これらのツールを探す方が時間を有効に使えるでしょう。
ドライブがたくさんあるのでしたら、緊急用としてスペアのブートパーティショ ンを別のドライブに用意しておいても良いかもしれません。ディスク容量は少々 損しますが、セットアップにかかる時間を考えれば、何かが壊れたときの保険と しては充分価値があります。
ルートパーティションを RAID0 のシステム上に置くのはお勧めできま せん。立ち上げ動作が複雑になりますし、障害の際にも問題があります。また、 ブートパーティションに RAID を使う場合は、レスキュー用カーネルの md 機 能を有効にしておくようにしてください。
異教徒と思われたくはないんですが、読者のみなさんが迫害しているこの手の ブツについても一節を設けることにしました。残念ながらハードウェアに付い てくる設定ツールには、この種の 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 動作するドライブは騒音や発熱量が大きくなりがちで す。この事は巨大なディスクアレイやディスクファームを作るときには気に留 めておく必要があるでしょう。
通常 MB/s という単位で記されます。このパラメータは大きなファイル群を扱 う場合に重要になります。ライブラリのファイルや、辞書、画像ファイルなど がこれに当たります。回転数の高いドライブでは転送速度も回転速度に比例し て大きくなります(セクタ密度が一定の場合)。
以上からわかるように、ドライブの性能表を注意深く読むことは重要です。ま たスペック中の最大転送速度は、オンボードキャッシュからの転送速度で与え られていることが多く、必ずしもディスクから直接転送するときの速度ではな いことに注意してください。
わざわざ低い信頼性のディスクを欲しがる人もいないでしょうが、古いディス クは信頼性が低いと思っておくほうが良いでしょう。ところで RAID の用途に は、いろいろな種類のディスクを混ぜて使うのが良いとされています(関連す る文書を見て下さい)。そうしておけば、ディスクが同時にクラッシュするこ とが避けやすくなるからです。
今のところ、ファイルシステム全体が故障したという報告は私は一つしか聞い たことがありません。しかし不安定なハードウェアは数多くの障害の原因にな るようです。
ファイルの大きさの平均値は、ドライブのパラメータを選択・決定するときに 重要な意味を持ちます。たくさんの小さなファイルを扱うときはシーク時間が、 大きなファイルを扱うときは転送速度が重要になります。多数の小さなファイ ルを扱う場合は SCSI のコマンドキュ−が有利に働きますが、転送速度に関し ては安い IDE のディスクも SCSI にそれほどひけをとりません。
手持ちのデバイスを最大限利用するにはどうすればよいかを判断するには、ど んな技術が現在利用可能で、それらはどのようなものなのかを知る必要があり ます。いつものことながら速度や信頼性、能力、柔軟さ、使い易さ、複雑さな どなど、一長一短があります。
この方法は、複数のディスクを並列に使うことによってアクセス時間やデー タ転送速度を向上させ、ディスクシステムの信頼性と速度とをを高めようとい うものです。チェックサムやミラーリングが信頼性向上の手法として用いられ ています。大きなサーバでは有効な方法ですが、シングルユーザのシステム には過剰な機能でしょう。既にたくさんのディスクがあるような場合には考慮 しても良いかもしれません。他の文書や FAQ なども見て下さい。
Linux で RAID を実現するには、カーネルの md モジュールを使ってソフト的 に行なう方法と、Linux 互換なコントローラを使ってハードウェア的に行なう 方法とがあります。どんなコントローラが使えるかについてはコントローラの ドキュメントを見て下さい。ハード的な方法のほうが高速ですし、おそらく安 全でもあるでしょう。しかしお金もかかります。
現在サポートされているハードウェアの SCSI RAID コントローラは、DPT 社 の SmartCache[I/III/IV] と SmartRAID [I/III/IV] シ リーズだけのようです。これらのコントローラは、標準カーネルの EATA-DMA ドライバでサポートされています。 DPT のホームページ にも有益な情報があります。製品の情報だけでなく、 RAID や SCSI に関する 一般的な解説も読むことができます。
RAID には何段階かのレベルがあり、それぞれ異なった機能を持っています。 ここではこれらの内容について簡単に説明します。ここに書いた内容の多くは RAID FAQ を参考にしました。 RAID に興味を持たれた方は参考にしてください。
RAID 0 を他のレベルと組み合わせて使うこともできます。様々な組み合わせ が可能なはずですが、私が見たことがあるのは 2〜3 種類です。これらは上に 紹介した RAID の各レベルよりもずっと複雑なシステムになります。
RAID 0/1 はストライピングと二重化を組み合わせたもので、非常に 速い転送速度とシーク速度、およびデータ冗長性が得られます。欠点はディス ク消費が激しいという点と、先程触れたようにシステムが複雑になってしまう という点です。
RAID 1/5 の組み合わせは冗長度確保における RAID5 の優位性とシー ク速度における RAID1 の優位性を組み合わせたものです。冗長性は RAID 0/1 に比べて改善されますが、それでもディスク消費はそれなりになります。この ようなシステムは通常 6 台以上のドライブから構成されます。複数のコント ローラや SCSI チャネルが利用される場合もあるでしょう。
大容量、高速、高信頼性のディスクシステムを構築する上で、複数のディスク、
パーティションを用いるのは効果的です。しかしちょっとイヤなこともありま
す。例えば /tmp
のパーティションが一杯になってしまったら、い
くらニューススプールが空いていても面倒なことになりますよね。ディスクを
またいで必要な分量をあてがうことは簡単ではありません。そこで、まさにこ
れを行なうのがボリューム管理システムというわけです。
ボリューム管理システムとしては現在のところ AFS と Veritas の二つが有名 です。他にも log file システムや信頼性、速度等の点において最適化され たいくつかのシステムがあります。
Veritas はまだ Linux には対応していません。また Veritas のデベロッパ達 がソースコードを公開せずにカーネルモジュールだけを販売することができるか もまだはっきりしません。ソースコードを公開すると内部の情報が全部解っちゃ いますんでね。とりあえずのところでは 彼らのホームページ にもこのシステムの機能に関しての記述があります。
MIT の Derek Atkins は AFS を Linux に移植し、また Linux AFS mailing List を準備してくれました。このメーリングリストは公開されています。メーリン グリストへの参加希望は linux-afs-request@mit.edu まで。またバグの報告は linux-afs-bugs@mit.edu へ送って下さい。
重要: AFS は暗号化技術を使っているので、アメリカ国外への持ち出しは許可 されていません。 AFS は現在 Transarc で販売されており、 WWW サイトもあ ります。最近 Web サーバのディレクトリ構造が変更されたようで、トップの ページの url しかわかりませんが、 http://www.transarc.com/ です。このページからたどれば、多くの一般的な情報や FAQ などを参照する ことができます。
ボリューム管理は長いこと Linux から欠けているものでした。ここで最新のニュ ース: 仮想パーティションシステムのプロジェクトが始まったようです。これ は IBM の AIX システムで実装されているようなボリューム管理機能の多くを Linux に移植することになるそうです。
Linux のカーネルプロジェクトにも同様の機能を実現しようとしているものが あります。 md がそれで、 1.3.69 からカーネルに取り込まれています。いま のところ spanning と RAID のみが実現されています。これはまだ開発段階で、 うまく働いた、働かないなど様々な報告が出ています。ディスクが全部消えた という報告例もありますので注意して使って下さい。
Linux の世界では ext2fs
が標準のシステムになっています。特殊
な目的のためには他のファイルシステムを選ぶのも良いでしょう。ニュースス
プールなどには log ファイルシステムのようなものが良いでしょうし、高い
信頼性が必要なデータには他の形式が必要になるでしょう。これらの話題は議
論の最中です。まだ選択肢は多くありませんが、着々と仕事が進められていま
す。 log ファイルシステムにはファイルチェックが非常に速いという利点も
あります。通常のファイルシステムの場合、 100 GB クラスのメールサーバでは
リブート後にファイルをチェックして稼動するまでに数日かかってしまうかも
しれません。
Minix
ファイルシステムは最も古くからあるもので、レスキューディス
クの一部のパッケージを除き、今日ではほとんど用いられなくなりました。
Xiafs
は一時期 Linux の標準の有力な候補となったこともありましたが、
今日では没落してしまったようです。
Yggdrasil の Adam Richter から最近ニュースにポストがありました。彼らは log ファイルシステムをもとにした圧縮ファイルシステムを作りかけたそうで すが、現在この作業は止まっているそうです。しかし作業が止まる前のバージョ ンは、彼らの ftp サーバから入手できるそうです。 Yggdrasil の ftp サーバ をチェックしてみてください。ここにはパッチ当てされた特殊なバージョンの カーネルが置いてあります。きっと将来的には公式カーネルの方にも取り込 まれるでしょう。
現在の ext2fs
にはアクセスコントロールリスト(ACL)など、将来
実現されるであろう機能のための領域が予約されています。将来のアップデー
トに注目です。ファイルアクセス時の圧縮/伸展機能を追加するかどうかの議
論もなされています。
暗号化ファイルシステムもありますが、これまた米国外への持ち出しは禁止さ れています。法的に問題が無い人だけ利用するようにして下さい。
ファイルシステムは学術的にも産業的にも研究開発が盛んな分野です。研究の 成果は無料で公開されることが多いようです。 Linux はこのような開発のプ ラットフォームになることが多いので、この分野での仕事はこれからも数多く なされるものと期待して良いでしょう。最新の結果に注目し続けましょう。
ディスクを圧縮するか、それともファイルを圧縮するのかは、特にファイルを 壊してしまう危険性を中心に活発に議論されている内容です。新しいものが好 きなシステム管理者にはいくつかの選択肢があります。カーネルモジュール、 外部ライブラリへのパッチなど色々な手法が存在しますが、それらの大部分に はまだ書き込み不可といったような各種の制限が残っています。開発は急ピッ チで進められており、この文書が出るころには間違いなくより高機能なものが 出ているでしょう。常に言えることですが最新版をチェックするようにして下 さい。ここにはいくつかのポインタのみを示します。
他にもいくつかのユーザファイルシステム(userfs)があります。 ftp を利 用するものや圧縮(arcfs)、 prototyping 機能を持つものが知られています。 他にもいろいろなものがあります。
最近のカーネルにはループデバイス(またはループバックデバイス)という機 能があります。これはファイルシステムそのものをひとつのファイルの中に押 し込めるものです。このシステムを使うと、圧縮や書庫化等の機能を持った新 しいファイルシステムが作れるかもしれません。
なおこのデバイスはネットワークのループバックデバイスとは関係ありません。
つい最近ですが ext2fs
を拡張して圧縮機能を持たせるパッケージ
がアナウンスされました。まだテスト段階ですので興味を持っているのは主に
カーネルハッカー達だけのようですが、近い将来には安定して広く用いられる
ようになるでしょう。
ここで示すトリックは、かつてドライブが遅くて容量も小さかった頃、そしてファ イルの大きさを見てからファイルの実際の配置を決めるようなファイルシステ ムがもてはやされていた頃、にはとても重要なものでした。しかし速度が非 常に向上し、ドライブやコントローラでのキャッシュが大きく賢くなった現在 ではそれほどの意味はなくなってきています。
しかし今日においても多少の性能向上の余地は残されています。そして世界制 覇が近づいた今日でさえも、これを早期に達成するにはわれわれは持ち得る全 ての技を使わなければならないのです !
この手法の意味を理解するためには、現在では失われてしまった知識「セクタ の位置によってディスクの性質がどのように変わるのか」を理解する必要があ ります。ディスクの回転中心から離れたトラックではデータの転送速度は速く なります。また真ん中あたりのトラックを起点/終点とするシークは、内側か ら外側、外側から内側へのシークよりも速いでしょう。
ほとんどのドライブは一定の角速度で回っており、一方各トラックにおけるデー タの線密度はだいたい一定になっています。これはすなわち、外側のトラック では内側のトラックに比べてずっと速い転送が行われるということです。従っ て大きなライブラリなどを置くのに適しています。
最近のディスクでは論理ジオメトリマップを使っているものもあります。これ は実際の物理的なマップ(ドライブそのもののマップ)とは異なっているため、 「真ん中辺の」トラックの見当をつけるのが少々難しくなるかもしれません。
セクタの転送速度は遅くなります。またシークの起点/終点にな る場合、シーク動作は遅くなります。
この部分は高い性能を必要としない領域に割り当てると良いでしょう。たとえ ば DOS やルートファイルシステム、プリントスプールなどです。
セクタの転送速度は一般に内側より速く、またシーク動作も速いです。
この特性はスワップや /tmp
、/var/tmp
など、頻繁に転送
要求がくるような領域に適しています。
セクタの転送速度は最も速いですが、シークタイムは内側と同じよ うに遅くなっています。
ライブラリなどの大きなファイルが置かれる領域をここに割り当てると良いで しょう。
頻繁にアクセスされるセクタをディスクの中ほどに置くことで、シークの際の
ヘッドの平均移動距離を下げ、シークタイムを減らすことができます。このよ
うにするには fdisk
や cfdisk
を実行してパーティショ
ンを真ん中あたりに作ったり、あるいは dd
コマンドを使ってディ
スク容量の半分ほどの大きさのファイルを作り、その後に頻繁に使われるファ
イルを作成する、といった方法があります。後者の方法では作業後にダミーファ
イルを消しておきます。いずれも空のディスクを使い始めるときの方法です。
後者の方法はニューススプールに使うと良いでしょう。データファイルが置か れる前に、ディレクトリ構造を中ほどのトラックに置くのです。この作業によっ て、多少ですがフラグメンテーションが減る効果も期待できます。
このちょっとしたおまじないは、普通のファイルシステムでも RAID システム でも使えます。 RAID では、真ん中当たりのセクタを計算するのが(不可能と までは言いませんが)ちょっと難しいかもしれません。最新の RAID のマニュ アルを見てみて下さい。