ドライブとパーティションを監視し続けることは システム管理者の義務であると言えます。 どこかのパーティションが一杯になってしまえば、 パーティション容量の再配置がすむまで システムは正しく働かなくなってしまうのですから。
パーティションとディスクの監視は df コマンドによって簡単に行えます。 頻繁に行うべきですし、 cron や他の管理ツールなどを使って定期的に行うようにするのも良いでしょう。
スワップパーティションも忘れないようにしましょう。
free や procinfo, top
といったメモリ利用の統計表示ツールを用いることで監視できます。
ドライブの使用状況のモニタはもうちょっと難しいですが、 ドライブ利用の競合を避けてシステムの性能を上げるには重要な作業です。 アクセス要求がひとつのディスクに偏らないようにしましょう。
ソフトウェアのパッケージをインストールするとき、 どこにどのファイルを配置するかについて 明確な意図を持つようにすることも重要です。 先に紹介したように、 GCC は実行バイナリをライブラリのディレクトリに置きます。 他にも歴史的な経緯から、わけのわからない配置をするパッケージもあります。 X11 なんかがそうですね。
お使いのシステムのディスクが一杯になりかけたら、
まず古いログを探して消去しましょう。
core ファイルも探してみましょう。シェルのグローバルな設定に
ulimit を正しく用いておくと、
core でシステムをいっぱいにせずにすみます。
これまでの部分をじっくりと読んできた方は、 すでに何回かバックアップの重要性に触れてきたことに気付いたでしょう。 クラッシュに当たってバックアップが機能していなかった、 あるいは存在すらしなかった場合に管理者に降りかかる災厄については 恐ろしい話がたくさんあります。クラッシュが起こってからじたばたするよりは、 普段からバックアップに投資しておく方がはるかに話は簡単になるはずです。
バックアップには色々な手段が可能ですが、この辺りの詳細は Backup-with-MSDOS-mini-HOWTO に記述があります。 この文書には DOS に関する話だけではなく、 一般的な情報や、より詳細な情報へのポインタも書いてあります。 (訳注: 日本語訳が http://www.linux.or.jp/JF/JFdocs/Backup-With-MSDOS.html にあります)
ただバックアップをとるだけでなく、 バックアップデータをちゃんと復元できるかどうかも確認しておきましょう。 恐い話をひとつ。心掛けの良かった管理者がクラッシュに遭遇。 「ああ、普段からバックアップを取っていて本当に良かった」 バックアップデータの復元をはじめたら、何とそのデータが壊れていた... 気をつけましょうね。
これはファイルシステムの設計によって随分違います。
早い段階からフラグメンテーションが起きてしまい、
しかもそれによって非常に速度が低下するようなシステムもあります。
幸いなことに ext2fs はそうではないので、
デフラグメントツールに関してもほとんど話題になることはありませんでした。
実はちゃんと存在しているのですが、これまではほとんど必要なかったのです。
なんらかの理由でデフラグメント作業が必要になった場合は、
バックアップとレストアを行なってしまうのが簡単でしょう。
例えばホームディレクトリのような小さな領域だけならば、
その領域を tar で別のパーティションに一時待避し、
アーカイブを確認して、
オリジナルを消してから再書き込みすれば良いでしょう。
ディスク領域の不足が、システムのあちこちに散らばっている
不必要なファイルを削除するだけで解消してしまうことも良くあるものです。
異常終了したプログラムは、さまざまなガラクタを、
思いもよらないような場所に残してしまうことが良くあります。
このような事故があった場合には、通常はコアダンプが残されます。
デバッグを行わないならば単に削除してかまいません。
コアダンプはどこにでも作成されますから、
ときどきグローバルに検索を行うと良いでしょう。
これには locate コマンドが便利です。
正常に終了しなかったプログラムは、
いろいろな種類の一時ファイルを残すこともあります。
これらは /tmp や /var/tmp に置かれ、
通常ならプログラムの終了時に自動的に削除されるはずのものです。
このような領域は再起動を行えばきれいにされるはずですが、
すべてがそうであるとは限りませんし、
uptime が長ければ大量のゴミが溜まることになってしまいます。
領域が足りなくなったら、注意しながら削除しましょう。
そのファイルが現在使われているものではないことを、
まず確認してから削除するようにしましょう。
file のようなユーティリティを用いれば、
そのファイルが何であるかわかることも多いです。
システムが動作している場合には、多くの記録が残されます。
それらの多くは /var/log ディレクトリに保存されます。
特に /var/log/messages は、
削除しないとどんどん大きくなります。
古いログファイルからなる小さなアーカイブを
いくつか用意しておくと良いと思います。
それらを比較すれば、システムがおかしくなりかかっていないかを
チェックすることができますから。
メールまたはニュースのシステムが正しく動作していないと、
スプール領域が余計に消費されます。
それぞれ /var/spool/mail と /var/spool/news です。
overview ファイルには注意すること。
このファイルには先頭にドットがついているので、
ls -l しただけでは見えません。
ls -Al を用いて、これらのファイルにも常に注意するように。
ユーザー領域のオーバーフローは特に難しい問題です。
システム管理者とユーザの間には、ずっと闘争が行われ続けています。
気転や交渉術が必要です。
時には実際に新たなドライブを購入してあげる必要もあるでしょう。
message-of-the-day の機能
(ログインしたときに /etc/motd の内容が表示される)
をうまく使いましょう。ディスクが足りなくなった場合は、
これでユーザーに知らせるようにしましょう。
また shell のデフォルトの設定で、
コアダンプファイルが作成されないようにしておけば、
余計な仕事がかなり減ると思います。
システムのあちこちに自分のファイルを隠そうとするような人たちもいます。
先頭にドットがつくファイルは ls コマンドでは見えませんので、
この点が良く利用されます。よくある例としては、 ... のような
ファイル名です。通常は見えませんし、 ls -al ではすべての
ディレクトリに存在している . や .. にまぎれてしまいます。
これに対する対抗策としては、 ls -Al を使うことです。
このオプションでは . と .. は見えませんが、その他の
ドットファイルは見えるようになります。
いかに大きなドライブと言えど、いずれは使いきってしまうときがやってきます。 そのころには技術の進歩によるコストパフォーマンスの向上も期待できるでしょう。 現在のところは 6.4 GB クラスが一番良いでしょうか。
たいていのマザーボードでは IDE は二つ (あるいは四つ) までしか接続できないので、 IDE ドライブを増設する場合には古いものが無駄になってしまう可能性が高いです。 一方 SCSI は narrow (8 bit) SCSI で 7、 wide (15 bit) SCSI で 15 まで接続することができます。 またホストアダプタによっては二つ以上のチャンネルを サポートしているものもありますし、 場合によっては二つ以上のホストアダプタを一つのシステムに使うこともできます。 筆者の個人的なお勧めですが、長期間に渡って利用するシステムには SCSI を選択しておく方が良いでしょう。
ここで問題になるのは、どこに新しいドライブをあてがうかです。
スプール領域の不足が増設の理由になることが多いので、この場合は
/var/spool 以下のどこかに
新しいディスクをマウントしてしまえば良いでしょう。
しかし一方、新しいディスクは高速でもあるでしょうから、
長い目で見た場合はシステム全体を再構成する方が良いかもしれません。
その場合は以前に使った設計書が役に立つでしょう。
システムのアップグレードが必要になった原因が /usr や
/var などのパーティションの容量の枯渇である場合には、
アップグレードの作業はやや面倒になります。
全体を好みの配布パッケージで
(おそらくこちらもアップグレードされてるでしょうから)
再インストールすることをまず考えてみると良いでしょう。
この場合には、現在の重要な設定を上書きしないように気をつける必要があります。
これらの多くは /etc ディレクトリにあるでしょう。
気を付けて作業を進め、
最新のバックアップとレスキューディスクを用意しておくようにしましょう。
もう一つの選択肢もあります。
新しいディレクトリを一時的なポイントにマウントして、
古いディレクトリの内容を単純にコピーします。
次に /etc/fstab を編集して新しい方を有効にし、
リブートしてちゃんと動いているかどうかをチェックします。
うまく行かなければレスキューディスクでリブートして
/etc/fstab を再編集し、もう一度トライしましょう。
ボリューム管理が Linux で使えるようになるまでは、 これらの手段はいずれも面倒ですし危険でもあります。 システムをバックアップからレストアするはめになることを覚悟しておくことです。
Tips-HOWTO ではディレクトリ構造を丸ごとコピーする方法として、以下
の例を挙げています:
(cd /source/directory; tar cf - . ) | (cd /dest/directory; tar xvfp -)
この手法によるディレクトリ移動は、すべての Unix システムで利用できますが、 覚えておくにはちょっと不便です。またツリーが深くなって、パス名が tar の扱える長さを越えてしまうと、この作業は失敗してしまいます (GNU tar では長いパス名も使えるように特別な拡張が施してあります)。
GNU の cp を使えるなら (Linux システムなら使えるはず)、 以下でも同じことができます。
cp -av /source/directory /dest/directory
GNU cp はシンボリックリンクや FIFO, デバイスファイルなどに 関してもちゃんと区別でき、正しくコピーを行えます。
ただし /dev や /proc を移動しようとするのは
あまり良い考えではないことも覚えておいてください。
システムのクラッシュは、さまざまな (面白い) かたちでやってきます。 特にパーティションテーブルが破壊されると、 たっぷりスリルを味わうことができます。 心臓の強くない人には、最近とてもとても便利なツールができました。 gpart これは「PC ハードディスクの形式を推定 (Guess PC-Type hard disk partitions)」してくれます。 有益です。