Solstice DiskSuite 4.2.1 ユーザーズガイド

トランスメタデバイスの障害の修復

トランスメタデバイスは、マスターデバイスとロギングデバイスから成る「階層構造」メタデバイスであり、しかもロギングデバイスは複数のファイルシステムで共有できるため、エラーの発生したトランスメタデバイスの修復には、特別な障害回復作業が必要となります。

デバイスエラーやファイルシステムのパニックが発生した場合、コマンド行ユーティリティを使用して対処することが必要です。

ファイルシステムのパニック

ファイルシステムが、その使用中に内部的な不一致を検出した場合、システムをパニック状態にします。ファイルシステムが UFS ロギング用に設定されている場合、リブート時にファイルシステムのチェックが必要であることをトランスメタデバイスに通知します。トランスメタデバイスは、自分自身を「Hard Error (ハードエラー)」状態に移行します。同じロギングデバイスを共有している他のトランスメタデバイスも、すべて「Hard Error」状態となります。

リブート時に、fsck はファイルシステムのチェックと修復を行なって、ファイルシステムの状態を「Okay (正常)」に戻します。この操作は、影響されるロギングデバイスの /etc/vfstab ファイルに記載されたすべてのトランスメタデバイスに対して行われます。

トランスメタデバイスのエラー

デバイスエラーによってデータが失われることがあります。ロギングデバイスに読み取りエラーが発生すると、重大なデータ損失を引き起こすことがあります。したがって、ロギングデバイスのミラー化を強くお勧めします。

トランスメタデバイスがログに記録されたデータの処理中に、マスターデバイスやロギングデバイスにデバイスエラーが発生した場合、そのデバイスは「Okay」状態から「Hard Error」状態に移行します。デバイスが「Hard Error」状態または「Error (エラー)」状態であれば、デバイスエラーかファイルシステムのパニックが発生しています。

注 -

エラーの発生したロギングデバイスを共有するデバイスも、すべて「Error」状態となります。

ファイルシステムのパニックを起こしたトランスメタデバイスの回復方法 (コマンド行)

fsck では修復できないファイルシステムの場合、影響されるロギングデバイスを共有するファイルシステムをもつ各トランスメタデバイス上で fsck を実行します。

例 - トランスメタデバイスの回復

# fsck /dev/md/rdsk/<トランスメタデバイス名>

影響を受けたすべてのトランスメタデバイスがチェックされ、正しく修復された後に限り、fsck はエラーの発生したトランスメタデバイスの状態を「Okay」にリセットします。

ハードエラーを起こしたトランスメタデバイスの回復方法 (コマンド行)

この作業は、トランスメタデバイスを「Okay (正常)」状態に移行するために使用します。

トランスメタデバイスの状態をチェックするには、「メタデバイスとホットスペア集合の状態のチェック方法 (コマンド行)」を参照してください。

ログに記録されたデータの処理中に、マスターデバイスまたはログデバイスにエラーが発生した場合、そのデバイスは「Okay」状態から「Hard Error (ハードエラー)」状態に移行します。デバイスが「Hard Error」状態または「Error (エラー)」状態にある場合、デバイスエラーかファイルシステムのパニックが発生しています。この 2 つの場合からの障害回復の作業は同じです。

注 -

ログ (ロギングデバイス) が共有される場合、トランスメタデバイス内のどれかのスライスに障害が発生すると、そのトランスメタデバイスに関連付けられたすべてのスライスやメタデバイスがエラー状態に切り換えられます。

この作業での手順を次に示します。

影響を受けたファイルシステムのマウント解除
アクセス可能なデータのバックアップ
デバイスエラーの修復
ファイルシステムの修復 (fsck(1M) または newfs(1M))

前提条件 (「DiskSuite オブジェクトを保守するための前提条件」) と予備情報 (「トランスメタデバイスの障害の修復」) をチェックしてから、lockfs(1M) コマンドを実行して、どのファイルシステムがロックされているかを調べる。
# lockfs
影響されるファイルシステムは、ロックタイプが hard となって表示されます。同じロギングデバイスを共有するファイルシステムは、すべてハードロックされます。

影響されるファイルシステムをマウント解除する。

ロックされたファイルシステムは、たとえエラーが発生したときに使用中であっても、マウント解除できます。影響されるプロセスが、ハードロックまたはマウント解除されたファイルシステム上の開かれたファイルやディレクトリにアクセスを試みると、EIO エラーが返されます。

[オプション] アクセス可能なデータをすべてバックアップする。

デバイスエラーの修復を試みる前に、できるだけ多くのデータを回収したい場合があります。バックアップ作業に、ファイルシステムをマウントする必要がある場合 (tar や cpio など)、ファイルシステムを読み取り専用にマウントできます。バックアップ作業に、マウントされたファイルシステムが必要ない場合 (dump や volcopy など)、トランスメタデバイスに直接アクセスできます。

デバイスエラーを修復する。

この時点では、トランスメタデバイスを読み書きアクセス用にオープンしたりマウントしたりすると、ロギングデバイス上のすべてのアクセス可能データは、適切なマスターデバイスにローリングを開始します。読み書きできないデータは、すべて破棄されます。しかし、トランスメタデバイスを読み取り専用アクセス用にオープンしたりマウントしたりすると、ログは単に再走査されるだけで、マスターデバイスにはロールフォワードされないため、エラーは修復されません。つまり、マスターデバイスとロギングデバイス上のすべてのデータは、最初の読み書きオープンやマウントまでは変化しません。

fsck(1M) を実行してファイルシステムを修復するか、データを復元する必要があれば newfs(1M) を実行する。

同じロギングデバイスを共有するすべてのトランスメタデバイス上で、fsck を実行します。これらのトランスメタデバイスが fsck によってすべて修復されると、「Okay」状態に戻ります。

newfs(1M) コマンドもファイルシステムを「Okay」状態に戻しますが、ファイルシステム上のデータはすべて破壊されます。一般に、バックアップからファイルシステムの復旧を計画するときは、newfs(1M) が使用されます。

同じロギングデバイスを共有するすべてのトランスメタデバイス上で fsck(1M) コマンドや newfs(1M) コマンドを実行すれば、それらのデバイスは「Okay」状態に戻ります。

metastat(1M) コマンドを実行して、影響されるデバイスの状態が「Okay」に戻ったことを確認する。

例 - ロギングデバイスのエラー

# metastat d5
d5: Trans
    State: Hard Error  
    Size: 10080 blocks
    Master Device: d4
    Logging Device: c0t0d0s6
 
d4: Mirror
    State: Okay
...
c0t0d0s6: Logging device for d5
    State: Hard Error
    Size: 5350 blocks
...
# fsck /dev/md/rdsk/d5
** /dev/md/rdsk/d5
** Last Mounted on /fs1
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
WARNING: md: logging device: /dev/dsk/c0t0d0s6 changed state to
Okay
4 files, 11 used, 4452 free (20 frags, 554 blocks, 0.4%
fragmentation)
# metastat d5
d5: Trans
    State: Okay
    Size: 10080 blocks
    Master Device: d4
    Logging Device: c0t0d0s6
 
d4: Mirror
    State: Okay
...
 
c0t0d0s6: Logging device for d5
    State: Okay
...

この例では、「Hard Error (ハードエラー)」状態のロギングデバイスをもつトランスメタデバイス d5 を修復します。トランスデバイス自身の上で fsck を実行しなければなりません。これによって、トランスメタデバイスの状態は「Okay」に移行します。metastat は、状態が「Okay」であることを確認します。