UFS ロギングおよびトランスメタデバイス

UFS ロギング

UFS ロギングとは、ファイルシステム「メタデータ」への更新内容を UFS ファイルシステムに適用する前に、ログに書き込むプロセスです。

UFS ロギングでは、UFS トランザクションをログに記録します。トランザクションをログに記録しておくことで、後でファイルシステムにトランザクション情報を適用することができます。

リブート時には、システムは不完全なトランザクションを破棄しますが、動作が完了したトランザクションは適用します。完了しているトランザクションのみがリブートのたびに適用されるため、ファイルシステムの整合性が保たれます。このように、ファイルシステムの整合性が損なわれることはないため、通常は fsck(1M) コマンドで整合性をチェックする必要はありません。

システムクラッシュが発生すると、現在のシステムコールが中断されて、UFS の整合性が損なわれることがあります。システムクラッシュが発生した後は、fsck(1M) コマンドで UFS ファイルシステムの整合性をチェックしてください。整合性をチェックせずにファイルシステムをマウントすると、システムパニックが発生したり、データが破壊されたりする場合があります。

整合性のチェックはデータを読み取って検証するため、大規模なファイルシステムのチェックには時間がかかります。UFS ロギングを使用すれば、完了していないシステムコールからの変更内容は必ず破棄されるため、UFS ファイルシステムをチェックする必要はなくなります。

DiskSuite は、トランスメタデバイスを介して UFS ロギングを管理します。

UFS ロギングの規約

• UFS ロギングがパフォーマンスに与える影響

  UFS ロギングは、ファイルシステムに対して fsck(1M) コマンドを実行する必要をなくすことによって、障害の発生後のリブート時間を短縮します。

• UFS ロギングの短所

  ログが満杯になると、UFS が新しい情報を書き込む前にログを空にしなければならなくなるため、パフォーマンスが低下します。

• UFS ロギングを使用できる Solaris バージョン

  UFS ロギングは、Solaris 2.4 以降で使用できます。

• ログの対象にならないファイルシステム

  UFS ではないファイルシステムとルート (/) ファイルシステムは、UFS ロギングの対象にはなりません。

トランスメタデバイス

トランスメタデバイスとは、UFS ロギングを管理するためのメタデバイスです。トランスメタデバイスは、マスターデバイスとロギングデバイスから構成されます。

マスターデバイスは、ロギングの対象となるファイルシステムが格納されているスライスまたはメタデバイスです。トランスメタデバイスがロギングデバイスを持っている場合には、そのトランスメタデバイスがマウントされた時点で自動的にロギングが開始されます。マスターデバイスに (トランスメタデバイスを作成してもマスターデバイスは変更されないため) 既存の UFS ファイルシステムを格納するか、もしくは後でトランスメタデバイス上でファイルシステムを作成することができます。同じように、トランスメタデバイスをクリアしても、マスターデバイス上の UFS ファイルシステムはそのまま残ります。

ロギンググデバイスは、ログが記録されるスライスまたはメタデバイスです。1 つのロギングデバイスを複数のトランスメタデバイスで共有することもできます。ログは一連のレコードで構成され、それぞれのレコードがファイルシステムへの変更内容を記述しています。

トランスメタデバイスには、他のメタデバイスと同じような名前 (/dev/md/dsk/d0、d1、d2 など) が付けられます。メタデバイス名についての説明は、表 1-4 を参照してください。

トランスメタデバイスの規約

• トランスメタデバイスの使用方法

  トランスメタデバイスを構成したら、物理スライスと同じように使用することができます。トランスメタデバイスは、ブロックデバイス (最大 2 G バイト) または raw デバイス (最大 1 T バイト) として使用できます。マスターデバイスがファイルシステムを持っていない場合には、トランスメタデバイス上に UFS ファイルシステムを作成することができます。

ロギングデバイスやマスターデバイスとしては、物理スライスまたはメタデバイスを使用できますが、信頼性と可用度を高めるためにはミラーを使用してください。物理的なロギングデバイスでエラーが発生すると、データが失われることがあります。ミラーや RAID5 メタデバイスをマスターデバイスとして使用することもできます。

• ロギングデバイスが必要とするディスク領域

  ロギングデバイスは、1 M バイト以上の領域を必要とします (領域が大きいほど多くのファイルシステムトランザクションを同時に実行できます) 。最大サイズは 1 G バイトです。 1 G バイトのファイルシステムに対して 1 M バイトのログ領域が最低限必要です。できれば 100 M バイトのファイルシステムに対して 1 M バイトのログ領域を確保してください。最適なログサイズを決める規則はありません。最適なログサイズは、各システムの負荷や構成によって異なります。ただし、ほとんどの場合には、64 M バイトを超えるログ領域は必要ありません。ログサイズを変更するのはさほど難しくありません。

• ロギング対象のファイルシステム

  一般には、最大の UFS ファイルシステムと、データがもっとも頻繁に変更される UFS ファイルシステムがロギングの対象となります。読み取りトランザクションがほとんどである小さなファイルシステムをロギングする必要はありません。

• ログを独立させる必要のあるファイルシステム

  すべてのファイルシステムは同じログを共有することができます。しかし、最も負荷が大きいファイルシステムのログを独立させると、パフォーマンスを向上させることができます。

Solaris システムでソフトウェアをインストールまたはアップグレードする際には、/usr、/var、/opt、および Solaris のアップグレードやインストールでシステムが使用するファイルシステムは、ロギング対象から外してください。

• ログの格納場所

  ログは、ミラー、未使用のスライス、または状態データベースの複製と同じスライスに格納します。物理的なロギングデバイス (スライス) でエラーが発生すると、データが失われることがあります。

• ロギングデバイス用のスライスが空いていない場合

  ロギングデバイス用のスライスが空いていない場合でも、トランスメタデバイスを構成することはできます。エクスポートしたファイルシステムをロギングする場合には、ロギングデバイス用に使用するスライスが空いていなくても、トランスメタデバイスは有用です。スライスが利用できるようになったら、ロギングデバイスとしてトランスメタデバイスに接続します。この方法についての説明は、『Solstice DiskSuite 4.2.1 ユーザーズガイド』を参照してください。

• 複数のトランスメタデバイスによるロギングデバイスの共有

  ロギングデバイスを複数のファイルシステムで共有することはできますが、負荷の大きなファイルシステムに対しては独立したロギングデバイスを用意してください。ロギングデバイスを共有する際のデメリットは、発生したエラーの種類によっては、そのロギングデバイスを共有しているすべてのファイルシステムを fsck(1M) コマンドでチェックしなければならないということです。

例 - トランスメタデバイス

図 2-8 に、ミラー化されたマスターデバイス d3 とミラー化されたロギングデバイス d30 から構成されるトランスメタデバイス d1 を示します。

図 2-8 トランスメタデバイスの例

例 - 共有ロギングデバイス

図 2-9 に、ミラー化されたロギングデバイス d30 を共有している 2 つのトランスメタデバイス d1 および d2 を示します。各マスターデバイスも、共有されているロギングデバイスと同じようにミラー化されたメタデバイスです。

図 2-9 ロギングデバイスを共有したトランスメタデバイスの例