Solaris のシステム管理 (基本編)

UFS ファイルシステム

UFS は、Solaris オペレーティング環境内のデフォルトのディスクベースファイルシステムです。ほとんどの場合、ディスクベースのファイルシステムを管理するときには、UFS を管理していることになります。UFS ファイルシステムの機能は次の通りです。

UFS の機能	説明
状態フラグ	ファイルシステムの状態を、クリーン、安定、使用中、ロギング処理、または不明として示します。これらのフラグによって、必要のないチェックをファイルシステム上で行わなくて済みます。ファイルシステムが「クリーン」状態、「安定」状態、または「ロギング処理」状態になっていると、ファイルシステムのチェックは実行されません。
拡張基礎タイプ (EFT)	32 ビットのユーザー ID (UID)、グループ ID (GID)、およびデバイス番号。
大規模ファイルシステム	UFS ファイルシステムの最大ファイルサイズは 1T バイト(テラバイト)です。Solaris オペレーティング環境では、論理スライスの大きさを 1T バイトのファイルシステムに対応させるストライプ機能はサポートされていません。ただし、Solaris ボリュームマネージャにはこの機能が含まれています。
大規模ファイル	デフォルトでは、UFS ファイルシステムは 2G バイト (ギガバイト) を超えるファイルを持つことができます。2G バイトの最大ファイルサイズ制限を有効にするには、`nolargefiles` マウントオプションを明示的に使用しなければなりません。

UFS ファイルシステム構造の詳細については、第 44 章「UFS ファイルシステム (参照情報)」を参照してください。

UFS ロギング

UFS ロギングは、トランザクション (完全な UFS 操作を構成する変更) をログに保存してから、そのトランザクションを UFS ファイルシステムに適用するプロセスです。保存されたトランザクションは、後でファイルシステムに適用できます。

システムはリブート時に、不完全なトランザクションを廃棄しますが、完結している操作のトランザクションは適用します。完結しているトランザクションだけが適用されるために、ファイルシステムの整合性が保たれます。通常であればシステムコールの実行が中断され、UFS ファイルシステムの整合性が確保できないシステムクラッシュ時にも、ファイルシステムの整合性が保たれます。

UFS ロギングには 2 つの長所があります。

1 つは、ファイルシステムの整合性が保持されるため、fsck コマンドを実行する必要がなくなることです。もう 1 つは、fsck による検査を省略できるため、システムがクラッシュしたり、異常停止 (クリーンではない停止) した場合でもシステムをリブートするのに要する時間を短縮できることです (クリーンではない停止については、fsck コマンドでチェックして修復される内容を参照)。
UFS ロギングを使用すれば、特に、通常であれば fsck コマンドによる読み込みと確認に時間がかかる大規模ファイルシステムを持つシステムのブート時間をかなり短縮できます。

UFS ロギングが作成するログは、いっぱいになるとフラッシュされます。また、ファイルシステムがマウント解除されたとき、あるいは lockfs -f コマンドを実行したときにも、ログはフラッシュされます。

デフォルトでは、UFS ロギングは無効です。UFS ロギングを有効にするには、ファイルシステムを手動でマウントするときか /etc/vfstab ファイル内で、-o logging オプションを指定して mount(1M) コマンドを実行する必要があります。ログはファイルシステムの空きブロックから割り当てられ、1G バイトのファイルシステムごとに約 1M バイトのサイズ (合計で 64M バイトまで) が割り当てられます。ログは、ルート (/) ファイルシステムを含む、任意の UFS ファイルシステムで有効にできます。また、fsdb コマンドには、UFS ロギングをサポートするための新しいデバッグコマンドが用意されています。

UFS ファイルシステムの計画

ファイルシステムの配置を決めるときには、要求が競合する可能性があることを考えなければなりません。次にいくつかの推奨事項を示します。

作業負荷を異なる入出力システムやディスクドライブ間でできるだけ均等に分散します。/export/home ファイルシステムやスワップ空間を異なるディスク間で均等に分散させます。
プロジェクトの個々の部分やグループのメンバーを同じファイルシステム内に入れます。
1 ディスク当たりのファイルシステム数をできるだけ少なくします。通常、システム (またはブート) ディスク上には、ルート (/)、/usr、スワップ空間の 3 つのファイルシステムがあります。他のディスク上では、1 つまたは多くても 2 つのファイルシステム (1 つはなるべく追加スワップ空間) を作成します。多数の小規模なファイルシステムに分割しすぎるよりもファイルシステム数を少なくして余地を設ける方が、ファイルがフラグメントに分割される可能性が小さくなります。容量の大きいテープドライブを使用し、ufsdump コマンドで複数のボリュームを処理できるようにしておけば、大規模なファイルシステムでも簡単にバックアップをとることができます。
絶えずきわめて小さいファイルを作成するユーザーがいる場合は、i ノード数を増やして別のファイルシステムを作成することを検討します。ただし、ほとんどのサイトでは、類似するタイプのファイルを同じファイルシステム内で保管する必要はありません。

デフォルトのファイルシステムパラメータや、新しい UFS ファイルシステムを作成する手順については、第 39 章「ファイルシステムの作成 (手順)」を参照してください。

UFS 直接入出力

直接入出力の目的は、大容量入出力処理のスピードを速くすることです。大容量入出力処理では、大規模ファイル (256K バイトを超える) を転送するために、大容量のバッファーサイズを使用します。

UFS の直接入出力を使用すると、データベースエンジンなど、独自の内部バッファリングを行うアプリケーションにメリットがあります。Solaris 8 1/01 リリースから開始された UFS の直接入出力は、raw デバイスのアクセス時に見られる同様の入出力の並行処理に対応するよう改善されました。現在では、パフォーマンスがわずかに低下するだけで、ファイルシステムのネーミングや柔軟性がもたらすメリットを受けることができます。データベースの製造元を調べて、その製品構成オプションで UFS の直接入出力を有効にできるかどうかを確認してください。

mount コマンドに forcedirectio オプションを使用しても、直接入出力をファイルシステムで有効にできます。直接入出力を有効にしてパフォーマンスが向上するのは、ファイルシステムが大量の連続するデータを転送するときだけです。

forcedirectio オプションでファイルシステムをマウントするとき、データはユーザーのアドレス空間とディスクの間で直接伝送されます。直接入出力がファイルシステムで無効な場合、ユーザーのアドレス空間とディスクの間で転送されるデータは、まず、カーネルアドレス空間にバッファーされます。

デフォルトでは、UFS ファイルシステムでは直接入出力は行われません。詳細は、mount_ufs(1M) のマニュアルページを参照してください。