UFS loggingによるエラーと復旧方法：UNIX処方箋

「事件は枯れたシステムが稼働する現場で起こってるんだ」と現場ですぐに役立つ知識を欲するあなたに贈る珠玉のTips集。今回は、UFS loggingによるエラーと復旧方法について解説する。

[ITmedia]

現在、Sun Blade 2000（Solaris 8）に複数の外付けディスクを接続して使用しています。先日、外付けディスクの電源ケーブルが抜けてしまい、一時的に電源オフの状態になりました。その後、電源ケーブルを差したのですが、一部の外付けディスクにだけアクセスできなくなり、リスト1のメッセージが表示されました。一度、アンマウントして再度マウントし直したら正常にアクセスできるようになったのですが、このような症状が一部のディスクにだけ発生した理由を教えてください。

ufs_log: [ID 702911 kern.warning] WARNING: Error writing master during ufs log roll
ufs_log: [ID 127457 kern.warning] WARNING: ufs log for /logmnt changed state to Error
ufs_log: [ID 616219 kern.warning] WARNING: Please umount(1M) /logmnt and run fsck(1M)

リスト1　表示されたメッセージ

---

アクセス時のワーニングメッセージから推測すると、問題が発生したディスク（ボリューム）はUFS loggingオプション付きでマウントし、発生しなかったディスクは同オプションなしでマウントしていたと考えられます。

　対処法を解説する前に、loggingオプションの役割について説明します。

loggingオプションの役割

　UFS loggingは、ファイルシステムの管理情報が更新された際、ファイルシステム上の管理情報を直接更新せず、更新内容を一度ログ領域に書き出し、その後ログ領域内の更新内容を実際のファイルシステムに反映する機能です。ファイルシステムの更新内容がすべてログ領域に書かれているため、パニック時などシステムが正常にシャットダウンされなかった場合でも、ログ領域の更新内容を確認するだけでファイルシステムの整合性を保証できます。従って、fsckコマンドでファイルシステムの全管理情報を走査する必要がなくなり、大容量ファイルシステムを持つシステムでは起動時間を短縮できるわけです。

　しかし、ハードウェアのエラーなどにより、ログ領域の更新内容が正常に読み出せなくなった場合、ファイルシステムの整合性の確認と修復を行うために、fsckによる全管理情報の走査が必要となります。質問のケースでは、外付けディスクの電源停止によって疑似的にハードウェアのエラーが発生したため、該当ボリュームへのアクセス時にログ領域の情報を読み出せず、電源停止以降のファイルシステムへのアクセスがすべてエラーになったわけです。

状態の確認と対策

　実際にマウントオプションの状態を確認するには、mountコマンドを実行します。

# mount

　実行例1の場合、/mount_0はloggingオプションが有効、/mount_1はloggingオプションが無効となります。なお、Solaris 9 9/04よりも古いOSにおけるUFSマウントは、デフォルトでloggingオプションが無効でしたが、Solaris 9 9/04以降では有効になっています。loggingオプションを無効にする場合は、mountコマンドやvfstabファイルにnologgingオプションを指定する必要があります。

# mount
        ：
        ：
/mount_0 on /dev/dsk/c4t0d0s2 read/write/setuid/intr/largefiles/logging/onerror=panic/dev=80055a
/mount_1 on /dev/dsk/c4t0d1s2 read/write/setuid/intr/largefiles/onerror=panic/dev=800562

実行例1　mountコマンドによる状態の確認

　loggingオプションが有効なボリュームで質問のようなエラーが発生した場合、一度該当ボリュームをアンマウントし、fsckコマンドでファイルシステムの整合性を確認の上、再度マウントしてください。特にエラーを出力せずに使用できたボリュームはログ領域を持たないため、ボリュームへのアクセスができれば直ちに使用できます。

　作業が増える分だけloggingオプションを無効にした方が便利そうに思えますが、ファイルの整合性が保証されないため、fsckを実行しない限りファイルシステムの整合性は確認できません。電源の停止したタイミングによっては、ファイルシステムの一部に障害が発生している可能性も考えられます。従って、loggingオプションが有効なボリュームと同様に、一度fsckを実施しておくことをお勧めします。