本稿は、先日刊行された書籍『Linux Power Tools』からの抜粋である。
変更と一口に言っても、中には手間のかかるものもある。たとえば、ファイルシステムを変更するには、バックアップ、新規ファイルシステムの作成、ファイルのリストアという手順が必要になる。ただし、ext2fsからext3fsへの変更だけは例外で、非常に簡単に行うことができる。ファイルシステムを切り替えたら、ファイルシステム作成のさまざまなオプションを利用して、新しいファイルシステムのパフォーマンスを向上させることができる。その他の変更は、比較的簡単だ。ディスクのデフラグ（パーティション全体に分散してしまっているファイルの内容を配置しなおす）や、必要な領域を確保するためのパーティションのリサイズなどがこれにあたる。
パフォーマンス最適化のためにファイルシステムを作成する
多くのファイルシステムには、パフォーマンスを左右するオプションが用意されている。たとえば、アロケーション・ブロックを大きくすると、断片化を防ぐことができ、1つのファイルを取得するのに必要な操作が減るので、パフォーマンスが改善される。このようなオプションには、ファイルシステムの作成時にしか指定できないものもあるが、後から変更できるものもある。また、どのファイルシステムにもすべての機能が用意されているわけではないので注意してほしい。Linuxのファイルシステムに用意されている、パフォーマンスを向上（または低下）させる重要かつ一般的なオプションは次のようなものだ。
アロケーション・ブロックのサイズ
「ディスク空間の消費量を最小限にする」で述べたとおり、アロケーション・ブロックを小さくすると、ディスク領域をより有効に使うことができるが、ディスクアクセスの速度が多少低下するというデメリットがある。よって、少しでもパフォーマンスを向上させたいなら、ブロックサイズを大きくしたほうがよいだろう。このオプションは、ファイルシステムを作成してからでは簡単には変更できない。ext2fsおよびext3fsでは、mke2fsで-b block-sizeオプションを使う。XFSでは、mkfs.xfsで-b size=block-sizeオプションを指定すればよい。ext2fsとext3fsでは、ブロックサイズは1024、2048、4096のいずれかでなければならない。XFSでは、理論的には512バイトに2のべき乗を掛けたサイズで、64KB（65536バイト）以下であればよいが、一般的なCPUを使っている場合、現実にファイルシステムをマウントできるブロックサイズは4KBか8KBのどちらかだ。ReiserFSとJFSのLinuxバージョンは、このオプションの調整にはまだ対応していない。
ジャーナリングのオプション
すべてのジャーナリング・ファイルシステムには、さまざまなジャーナル・オプションが用意されている。その1つに、ジャーナルの配置場所がある。メインのファイルシステムとは別の物理ディスクにジャーナルを配置すれば、パフォーマンスが向上する（ただし、ジャーナル用のディスクが非常に低速である場合はこの限りではない）。これを設定するには、mke2fsで-J device=journal-deviceオプションを指定するか、mkreiserfsで-j journal-deviceオプションを指定するか、またはmkfs.jfsを実行する。Ext3fsでは、-J size=journal-sizeオプションを使ってジャーナルのサイズも設定できる。journal-sizeはメガバイトで指定し、1024ファイルシステムブロックから102400ファイルシステムブロックまでの間でなければならない。ジャーナルのサイズを小さくしすぎるとパフォーマンスに悪影響を与えるが、逆に大きくしすぎても、大量のディスク領域を消費してしまう。最適なジャーナルサイズを判断できない場合は、mke2fsが自動的に割り当てるサイズを使えばよいだろう。
予約ブロック
ext2fsとext3fsは、スーパーユーザ（もしくは指定されたその他のユーザ）が使うためのブロックを大量に予約する。予約領域のデフォルト値は5％だが、大きなパーティションや、それほど重要でないパーティション（/homeなど）では、これでは多すぎる場合がある。mke2fsで-m reserved-percentageオプションを使用すれば、使用可能な領域を多少増やすことができる。この割合を変更しても、実際のディスクパフォーマンスには影響しないが、使用可能なディスク領域が少し増える。このオプションは、ファイルシステムを作成した後でも、mke2fsに指定するのと同じパラメータをtune2fsプログラムに渡すことで変更できる。たとえば、予約ブロックの割合を1％にしたい場合には、tune2fs -m 1 /dev/hda4と指定する。
チェック間隔
ext2fsとext3fsは、指定されたマウント回数後、またはマウントとマウントの間の指定された時間ごとにファイルシステムのチェックを実行する。この目的は、ランダムディスク書き込みのエラーやファイルシステムドライバのバグなどが原因となってファイルシステム上で起きるエラーを検知することだ。このチェックの間隔は、tune2fsに-c max-mount-countsオプションと-i interval-between-checksオプションを指定することで変更できる。2つ目のオプションでは、数字の後にd、w、mを付け、間隔を日、週、月単位で指定することができる。チェック間隔を変更しても毎日のパフォーマンスは変わらないが、コンピュータが起動時に行うフルディスクチェックの頻度に影響する。このディスクチェックは、ext3fsにおいてさえ非常に時間がかかる。システムのクラッシュの後で行われる強制チェックと同様、このチェックも、ジャーナルに記録された最近のトランザクションに限らずチェックを行うからだ。
ディレクトリのハッシュ
ReiserFSでは、ディレクトリのルックアップを高速化するために、ソート済みのディレクトリ構造を使用する。このために使用されるハッシュ（ルックアップアルゴリズムの一種）は、mkreiserfsで指定できる。mkreiserfsに-h hashオプションを指定する。hashには、r5、rupasov、teaのいずれかを指定する。一部のハッシュは、特定のアプリケーションのパフォーマンスを向上させたり低下させたりする。たとえば、Squid Webプロキシのマニュアルはrupasovハッシュを使うよう指定しているし、qmailのマニュアルではr5を推奨している。r5およびrupasovハッシュの問題点は、大量のファイル（100万個以上）があるディレクトリ内でのファイル作成が非常に遅くなることだ。rupasovはこの傾向が特に強いので、ほとんどのシステムではrupasovの使用は避けるべきだ。teaハッシュではこの問題がない代わりに、標準的な数のファイルが含まれるディレクトリではr5よりもはるかに低速になる。一般的には、デフォルトであるr5ハッシュを使うべきだ。ただし、大量のファイルを作成することがわかっている場合や、高いパフォーマンスが要求されるアプリケーションでそのディスクを使う場合には、アプリケーションのマニュアルを参照するかWebを検索して、どれが適切かを調べてみるとよいだろう。
inodeオプション
XFSでは、ファイルシステム作成時にinodeのサイズを指定することができる。これには、mkfs.xfsに-i size=valueオプションを指定する。最小サイズは256バイトで、これがデフォルトのサイズである。最大サイズは2048バイトだ（ただし、inodeのサイズはアロケーションブロックサイズの半分を超えてはならない）。inodeサイズのオプションを設定すると、小さなファイルへのアクセス時間に影響が出る。XFSは、inode内の大きなファイルを格納する大きなinodeを指定することで、小さなファイルをできる限りinode内に格納しようとする。こうすることで、各ファイルへのアクセス速度が速くなるのだ。よって、多数の小さなファイル（2KB以下）を格納するパーティションでは、inodeのサイズを大きくするとよいだろう。ディスク領域が浪費されるか節約されるかは、ファイルサイズの具体的な組み合わせによって決まる。2KBを下回るファイルが数個しかないなら、inodeのサイズを大きくするメリットはあまりないだろう。
ファイルシステム作成時のデフォルトのオプションでも、それなりのパフォーマンスが実現されることが多い。このオプションを変更する必要があるのは、大量のファイルを格納するファイルシステムや、頻繁に再起動されるコンピュータなど、一部の特殊なケースに限られる。自分の環境に合った設定を調べる目的であればともかくとして、めったやたらに変更を加えるのはお勧めしない。
ext2fsをext3fsに変換する
他のジャーナリング・ファイルシステムと比較した場合のext3fsのメリットの1つは、既存のext2ファイルシステムからの変換が簡単に行えることだ。変換には、tune2fsプログラムと-jオプションを使う。
# tune2fs -j /dev/hda4
この変更を加える際に、ジャーナルを追加するファイルシステムがマウントされている場合は、tune2fsはジャーナルを「.journal」という名前の通常のファイルとして、ファイルシステムのルートディレクトリに作成する。逆に、このコマンドを実行する時にファイルシステムがアンマウントされている場合は、ジャーナルファイルは通常のファイルとしては表示されない。どちらの場合にも、ファイルシステムはext3に変換されており、最初からext3ファイルシステムとして作成した場合となんら変わりなく利用できる。必要に応じて、ext2fsとしてファイルシステムにアクセスする（ext3fsサポートのないカーネルを使っている場合など）こともできるが、一部の古いカーネルや非Linuxユーティリティでは、このようなアクセスができなかったり、読み取り専用アクセスしかできなかったりすることがある。
まれにではあるが、ext3ファイルシステムのジャーナルが破損して、ディスクリカバリの作業に支障をきたすことがある。このような場合は、debugfsツールを使ってファイルシステムをext2に戻す。
# debugfs -w /dev/sda4 debugfs 1.32 (09-Nov-2002) debugfs: features -needs_recovery -has_journal Filesystem features: dir_index filetype sparse_super debugfs: quit
これが済んだら、次節「ファイルシステムチェックのオプション」で説明するとおり、-fオプションと共にfsck.ext2を実行してファイルシステムのリカバリを行えるようになるはずだ。これまではエラーが出ていなかったとしても、無効にされたジャーナルが原因で、fsck.ext2がエラーを報告することがある。必要であれば、先ほど説明したとおりにtune2fsを使って、ジャーナルを再度追加することもできる（マウントされているファイルシステムでジャーナルを削除しないこと）。
次回は、その他のファイルシステム操作（ファイルシステムのリサイズ、ディスクのデフラグ）を見ていく予定だ。