パーティション分割／非分割のセオリー

今回のお題は、パーティションです。WindowsとLinuxではパーティションに対する考え方もちょっと違います。私自身、初めてSlackwareをインストールするときにずいぶん悩んだものです。

PC/AT互換機におけるパーティション

　Windowsでは、原則として分割されたパーティションには独立したドライブ名が割り当てられます（図1）。これはHDDが普及し始めたころのMS-DOS Ver.3.xに由来すると思われます。当時、PC/AT互換機用のMS-DOS Ver.3.xはファイルシステムの制限で32Mbytesまでしか扱えませんでした。そこでHDDを複数の区画に分けて、各区画を32Mbytes以下とすることですべての領域を使おう、というのがパーティションの始まりではないかと想像しています。さらにさかのぼれば、ドライブ名という発想はインテルの8080という8bits CPU用OSであるCP/Mにまでたどれるでしょう。それ以前にはマイコン用のメジャーなOSは存在しませんでした。

図1　DOS／Windowsのパーティション管理方法。各パーティションは「ドライブ」と呼ばれ、各ドライブは独立したディレクトリツリー構造を持つ。また、パーティション形式（基本、論理ドライブなど）によりドライブレターが変動する

　余談ながら、同じMS-DOS Ver.3.xでもPC-9800シリーズ用では32Mbytesの制限を受けた記憶がありません。改良したのか、そもそもPC/ATとPC-9800シリーズのアーキテクチャ上の違いだったのかは判然としませんが……。また、PC-9800シリーズ用のMS-DOSではformat.exeが領域管理とフォーマットの両方を行っていました。対してPC/AT互換機用ではfdisk.exeで領域を操作し、format.exeでフォーマットを行うようになっていました。PC-9800シリーズからPC/AT互換機に乗り換えた当初はこれが分からず、苦労したものです。

　また、原則としてPC/AT互換機では1つのHDDに確保できるパーティションは4つまでです。これには回避策があって、拡張パーティションを使えばさらに増やせます（編注）。

Linuxにおけるパーティション

　Linuxのファイル名空間は1つです。つまり、HDDはすべて「/」（ルート）から順にたどっていけます。ハードウェア的には完全に独立したHDDであっても、これは変わりません（図2）。というよりも、Linuxの先輩であるUNIXが開発されたころはそれほど容量の大きなHDDがなく、複数のHDDを1つにまとめざるを得なかったということでしょう。

　ちょっと実例を挙げてみましょう。話を簡単にするため、4GbytesのHDDを2Gbytesの基本パーティションと2Gbytesの拡張パーティションに分けているとします。Windowsでは基本パーティションがCドライブ、拡張パーティションがDドライブとなり、それぞれが独立したディレクトリ構造を持ちます。

　対してLinuxでは、もう少し融通が利きます。とりあえず、基本パーティションを/ファイルシステムとして使うことにしましょう。あとは、

図2　UNIX／Linuxのパーティション管理方法。各パーティションは、物理的に異なるドライブであっても/ディレクトリ下にディレクトリとしてマウントされ、単一のディレクトリツリーを構成する

とすることで、拡張パーティションを/home以下に割り当てられます。こうすると、2つのパーティションは見かけ上1つのディレクトリ構造になるわけです。実際には、/ファイルシステムにいくら空きがあっても、/homeファイルシステムがいっぱいになるとそれ以上/home以下にはファイルを追加できなくなるのですが。

　実は、MS-DOSにもかつてこれと同じ働きをするjoinコマンドが用意されていました。が、MS-DOS Ver.5のころにはなくなっています。これは優劣の問題ではなく、文化的なバックグラウンドが違っていたためでしょう。

　逆に、/dev/hda5を/ファイルシステムにして、/homeに/dev/hda1を割り当てることもできます。実際にはいちいち手でコマンドを打ち込むのではなく、/etc/fstabの記述に従ってファイルシステムがマウントされます。HDDを増設した場合も、/etc/fstabの記述を変更することでファイルシステムに追加します。

　なお、Linuxでは最初に見つかったIDE HDDから順にhda、hdb、hdcと名前を付けていきます。パーティションを表すときは、その後に数字を付けます。hda1は最初の基本パーティションで、hda2は2番目の基本パーティションです。拡張パーティションは5から始まります。Windowsのfdisk.exeに慣れていると複数の基本パーティションを作れるのが不思議に思えますが、Linuxのfdiskでは可能なのです（編注）。

　さて、現在のLinuxで標準的に使われているext2というファイルシステムでは、理論的に4Tbytesのパーティションまで扱えます。これだけを見れば、当分の間1台のHDDを1つのパーティションで使えそうです。ただし、現実問題としては4Gbytes、8Gbytes、34Gbytesあたりにさまざまな規格上の制約があります。IDEやBIOSの規格を決めたときには、まさかこれほど大容量のHDDが使えるようになるとは予想していなかったためです。

　実際、私が使っていたマザーボードでは、10GbytesのHDDを認識しないどころか、ブートシーケンスがそこで止まってしまうというありさまでした。ただこれはBIOSの問題だったようです。ブート用に小さなHDDを用意して、10Gbytes HDDの認識をスキップすることで無事使えました。こうした制限に関しては、http://www.linux.or.jp/JF/JFdocs/Large-Disk-HOWTO.htmlに解説されています。

　一般的に、新しいマザーボードほど制約が少なくなっています。しかし、中にはHDDの全容量を認識できないまでもマシン自体の起動が可能で、しかしながら巨大なパーティションからはOSをブートできない、という場合もあり得ます。こうしたときは、カーネルを収めるための領域を100Mbytesくらい確保する必要があるかもしれません。いったんブートしてカーネルがHDDの容量を正しく認識すれば、BIOSがどうであろうと関係ないので、カーネルを収めたパーティション以外は自由に配置できます。

　PC/AT互換機のBIOSはシングルタスクのMS-DOSを前提とした設計で、マルチユーザー／マルチタスクのOSでは使えないのです。BIOSを使うのはブート時だけで、カーネルが動き出した時点ではまったく使わなくなり、BIOSの制限は問題にならなくなります。これはWindowsでも同様で、カーネルをメモリに読み込んで制御を移すカーネルローダさえBIOSで読み込めれば何とかなります。

分割するべきか非分割か、それが問題だ

　それでは、一般論としてファイルシステムをパーティションで分割するメリット、デメリットを考えてみましょう。

　まずメリットから考えると、バックアップやアップデートが楽になります。定期的にバックアップする必要があるのは、変化していくデータとユーザーのデータです。この2つをシステムとは別のパーティションに分ければ、バックアップするのはそのパーティションだけでよくなります。システムのアップデートを行っても、ユーザーデータの入ったパーティションをフォーマットしないようにすればちゃんと残ります。

　さらに、作業用のファイルシステム（一般的には/varや/tmp）を独立させておくと、システムやユーザーデータへの影響を小さくできます。例えば、だれかが50Mbytesのメールを出したとしましょう。このメールでファイルシステム（編注）があふれたとしても、パーティションを分けておけばシステムやユーザーが使うパーティションにはまだ余裕があるというわけです。まあ実際には、作業用のパーティションがいっぱいになった時点でかなり制限を受けますが、よほどのことがない限りシステムやユーザーデータが書き換わってしまうという心配はしなくて済みます。

　デメリットとしては、見積もりを誤るとパーティションの使用率に偏りが出ることです。単に偏るだけならまだいいのですが、/usrは余っているのに/varが足りないとか、/homeを使い切ってしまった、などになると深刻です。まあ最近はHDDが安いので、追加すれば解決するのですが。使用量の見積もりは結構難しくて、どんな仕事をさせるのか、どのくらいの規模になるのかで変わってきます。

　では、HDDを複数のパーティションに分割するべきでしょうか？

　慣れないうちは練習ということで、全部1つのパーティションにしてしまって様子を見るというのもいいでしょう。これで当たりを付けてから、次にインストールするときには適当にパーティションを分けるのです。

　このあたり、実はWindowsでも事情は大差なかったりします。私はシステムをインストールするドライブと、アプリケーションをインストールするドライブ、作ったデータを保存しておくドライブと、最低でも3つのドライブを作成して使っています。本当に大事なファイルはファイルサーバに保存して、毎朝7時にテープでバックアップするようにしています。

　閑話休題、いくつか実例を挙げておきましょう。

■パーティション分割例 1

　まずは、自宅でファイルサーバに使っているLinuxマシンから。このマシンは、

となっています。ちょっと特殊ですが、まず1台目のIDE HDDを3つのパーティションに分けています。300Mbytesの/ファイルシステムと3.5Gbytesの/usrファイルシステム、そして128Mbytesのスワップ領域です（dfコマンドではスワップ領域は表示されません）。最後のmd0は、ソフトウェアでストライピングを実現しているドライブです。実際には40Gbytesクラスのドライブを3台まとめています。このとき、/dev/hdcで4Gbytesほど領域が余ったので、ここを/tmpに割り当てています。

　使っているディストリビューションはDebian GNU/Linux 2.2で、後からパッケージとして追加できるソフトウェアは/usrに配置されます。基本的なシステムだけなら300Mbytesもあれば十分で、これ以上増えることはありません。/usrの下にはユーザーのホームディレクトリも含まれますから、ここは別のパーティションにしてあります。欲をいえば、作業エリアである/varも独立させたいところですが、ファイルサーバならそれほど/varを使うこともないようなのでこうしています。

■パーティション分割例 2

　次に外部向けに公開しているサーバだと、

です。これはFreeBSDなのでデバイスの表記が違いますが、パーティションを分けるという点ではLinuxと共通するものがあります。

　10GbytesのHDDを64Mbytesの/、3Gbytesの/usr、100Mbytesの/varとに分け、残りの6Gbytes弱をネットワーク経由で使えるファイル置き場に、100Mbytesをスワップ領域にしています。スワップが中途半端なのは、OSをバージョンアップした際に/ファイルシステムが足りなくなったため、スワップを削って/ファイルシステムに回したわけです。結局バージョンアップではなく再インストールになりましたが、データの収まっている/usrと/usr/share/publicは別のパーティション（正確にいうと、FreeBSDではスライス）だったので壊さずに済みました。ファイルシステムを分割しておいたメリットを享受できたわけですね。

　Linuxと比べると、/の容量が少なくなっています。このマシンはメールサーバでもあり、各人あてにきたメールを保存しているので、ホームディレクトリのある/usrは少し大きめにしてあります。また、外部に公開しているとはいえ個人ベースの代物ですから、/varはかわいいものです。会社の業務で使うなら、もっと増やさないといけないかもしれません。

■パーティション分割例 3

　もう1台、ADSL回線につなげてプロキシサーバとして使っているマシンだと、こんな具合です。

　3.8GbytesのHDDに128Mbytesのスワップ領域と50Mbytesの/、20Mbytesの/var、そして残りが/usrです。実は、インストーラのデフォルトをそのまま使っているようなものです。これはプロキシサーバ専用なので、あまり深く考えていないのです。

　なお、ファイルシステムをパーティションに振り分けるとき、/bin、/etc、/root、/sbinは/と同じパーティションにしておいた方がいいでしょう（別のパーティションに分けない、というべきでしょうか）。/binと/sbinには基本的なコマンドが入っています。/etcには各種設定ファイルがあり、/rootはスーパーユーザーのホームディレクトリです（各ディレクトリの役割については、次回で詳しく解説します）。つまり、このパーティションさえ無事なら、多少の修復作業を行えるというわけです。

悩ましいスワップ領域確保

　パーティションの設定はそうそう行うものではなく、だいたいインストール時にやれば終わりです。Windowsとのデュアルブートにするのなら最低でもWindows用とLinux用の2つのパーティションが必要です。Linux専用なら、最低1つのパーティションということになります。

　ここで悩ましいのが、スワップ領域（スワップ用のパーティション）です。スワップ用パーティションは仮想メモリを使うためのもので、仮想メモリは実装しているメモリよりも大きなメモリがあるかのように見せかけるための仕掛けです。

　ただ現在では64Mbytes、多い人は512Mbytesなどというメモリを実装しているのでいささか事情が違います。例えば私の作業用マシンは256Mbytesのメモリを実装しているのですが、長らくWindows 2000のページングファイルを0にして使っていました。これは意図して行ったのではなく、何の拍子かそういった設定になっていたのです。別段支障なく使えていたので全然気が付かず、何げなくページングファイルを確認して驚いたというわけです。これだけメモリがあると、たいていの作業は全部オンメモリで行えるのか、スワップが発生しなかったのです。自宅で使っている3台のサーバは、メモリを64Mbytesないし128Mbytes載せてLinuxやFreeBSDを動かしていますが、これらもスワップが発生している気配がありません。

　また、スワップが発生すると確実に実行速度が落ちます。メモリが高価だった時代ならいざ知らず、いまや256Mbytesのメモリが5000円以下で買える時代です。スワップ領域など使わないように、メモリをたくさん実装するのもあながち的はずれではないでしょう。Linuxでは、プロセスが使わないメモリはファイルキャッシュとして使われるので、たくさんメモリを実装しても無駄にはなりません。

　しかし、プログラムによっては積極的にスワップを使うものもあるようです。このため、スワップ領域をなくすわけにもいきません。昔は「実メモリの2倍」ともいわれていましたが、経験的には64Mbytesもあれば十分という気がします。もちろん、これもやらせる仕事の内容と規模によって変わってきます。後からファイルシステム上にスワップファイルを作ることもできるので、とりあえず64Mbytes確保して様子を見るのが無難です。

　BIOSやブートローダが対応しているなら、64Mbytesをスワップ領域にして、残りすべてを/ファイルシステムに分けるのをお勧めします。もし、BIOSやブートローダの制限でうまくカーネルをロードできないなら、/ファイルシステムをHDDの先頭から1Gbytes確保して、残りの中から64Mbytesのスワップ領域、あとは/usrファイルシステムという構成が簡単で分かりやすいでしょう。もっと細かい分割は、運用に慣れてから考えればいいのです。

　ちなみに、FreeBSDのインストーラは、デフォルトでは/、/usr、/var、スワップの4つを独立したファイルシステムとして設定します。

注意が必要なパーティション操作

　実はもっと大変なことがあります。それは、非破壊的にパーティションを変更するツールは、Windowsに標準装備されていないということです。つまり、すでにWindowsのインストールされたマシンにLinuxを入れようとしてパーティションを変更すると、いま使っているWindowsがきれいさっぱり消えてしまいます。

　もちろん、非標準なら内容を壊さずにパーティションを変更できるプログラムもあります。フリーのものではFIPSが有名です。また、商用だとPartition Magicが嚆矢です。FIPSはコマンドラインツールで、事前にデフラグをかけておく必要があります。MS-DOSプロンプトでの作業に慣れていないなら、Partiton Magicの方が失敗の可能性は低いでしょう。ただ、最近の大容量HDDに対応しているかどうかはきちんと確認する必要があります。どちらのツールもあまり失敗したという話は聞きませんが、操作ミスなどに備えてデータのバックアップを取っておいた方が確実です。

　パーティションの作成がうまくいったとしても、今度はデュアルブートの設定をしなければなりません。このあたりは趣味として楽しむ分には面白いのですが、仕事で使うなら面倒この上ありません。失敗したときのダメージも大きくなります。増設したHDDにインストールする方法もありますが、慣れないと解説書の記述とは微妙に違ってこれまた混乱します。安心して作業するためにも、専用マシンを用意して作業することをお勧めします。