XFS ファイルシステム破損の評価および復旧

CA6000 および CA6300 のアプライアンスに該当

問題： アプライアンスの再起動時、カーネルパニックの前に以下のような XFS コードコールスタックが表示されます。

RIP [<ffffffff883cf607>] :xfs:xfs_error_report+0xf/0x58
RSP <ffff81028c817c28>
CR2: 0000000000000118
<0> Kernel panic – not syncing – Fatal exception

解決策： 破損した XFS ファイルシステムをできるだけ早く復旧することをお勧めします。通常、XFS ファイルシステムが破損すると、上記に似た Linux カーネルパニックおよびシステム停止が発生します。

CA Multi-Port Monitor アプライアンスは、以下の 2 つのパーティションで高パフォーマンスの Linux XFS ファイルシステムを使用しています。

CA6300 の場合：
/nqxfs 上にマウントされた /dev/sdb1 は Vertica メトリックデータベースをホストします。

/data 上にマウントされた /dev/sdb2 は CA Multi-Port Monitor パケットキャプチャストレージをホストします。
CA6000 の場合：
/nqxfs 上にマウントされた /dev/sda4 は Vertica メトリックデータベースをホストします。

/data 上にマウントされた /dev/sdb1 は CA Multi-Port Monitor パケットキャプチャストレージをホストします。

XFS ファイルシステムが破損するのは、通常、アプライアンスで停電またはハードウェアハングアップが発生した場合です。

Linux カーネルパニックはほとんどの場合、アプライアンスが再起動した直後、Vertica メトリックデータベースが開始されたときに /nqxfs パーティションで発生します。以下の例では、端末画面に XFS コールスタックおよびカーネルパニックが表示されています。影響を受けたパーティションが表示されない可能性はありますが、両方の XFS パーティション（/nqxfs および /data）で安全に xfs_repair を実行して、XFS ファイルシステムの破損をすべて修復することができます。 NetQoS--MTP--XFS ファイルシステム破損の復旧

XFS ファイルシステムを修復して、そのファイルシステム上の破損を解決します。破損が /nqfxs パーティション（Vertica メトリックデータベースが存在する場所）で発生した場合は、Vertica メトリックデータベースを再作成します。

詳細：

アプライアンスのシャットダウンまたは再起動

XFS ファイルシステム破損の修復

CA6000 および CA6300 のアプライアンスに該当

影響を受けたパーティション上で xfs_repair コマンドを使用して、破損した XFS ファイルシステムを修復します。 XFS ファイルシステムの破損を修復した後に必要な操作は以下のとおりです。

/data パーティションの場合、それ以上のアクションは必要ありません。
/nqxfs パーティションの場合、そのパーティションでホストされている Vertica メトリックデータベースを再作成します。

XFS 修復の完了までの予想時間： 30 ～ 60 分

次の手順に従ってください：

Multi-Port Monitor の端末にカーネルパニックおよびシステム停止メッセージが表示されて応答がない場合、電源ボタンを数秒間押し続けてアプライアンスをシャットダウンします。それ以外の場合は、通常の方法でアプライアンスをシャットダウンします。
電源ボタンを押してアプライアンスを起動します。
BIOS スキャンの後、CentOS 初期起動画面が表示されます。カウントダウンがゼロ秒になる前に任意のキーを押して、起動メニューを表示します。
デフォルトの起動カーネルがあらかじめ選択されています。 a キーを押して、カーネルの起動パラメータを変更します。
カーソルはカーネルパラメータ行の最後にあります。以下の例に示すように、行の最後にパラメータ single を追加し、Enter キーを押します。
カーネルの起動が完了すると、コマンドプロンプトが表示されます。システムはシングルユーザモードで実行されているため、ログインプロンプトは表示されません。
注：シングルユーザモードでは、アプライアンスは端末画面からのみアクセスできます。
パーティションを修復します。
CA6300 用の /nqxfs パーティション
マウント解除して、そのブロックデバイスに xfs_repair を実行します。
```
umount /nqxfs
xfs_repair /dev/sdb1
```
CA6300 用の /data パーティション
マウント解除して、そのブロックデバイスに xfs_repair を実行します。
```
umount /data
xfs_repair /dev/sdb2
```
CA6000 用の /nqxfs パーティション
マウント解除して、そのブロックデバイスに xfs_repair を実行します。
```
umount /nqxfs
xfs_repair /dev/sda4
```
CA6000 用の /data パーティション
マウント解除して、そのブロックデバイスに xfs_repair を実行します。
```
umount /data
xfs_repair /dev/sdb1
```

いずれの場合も、修復が成功すると以下のようなテキスト出力が生成されます。

Phase 1 - find and verify superblock...
Phase 2 - zero log...
        - scan file system freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        ...
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - clear lost+found (if it exists) ...
        - clearing existing “lost+found” inode
        - deleting existing “lost+found” entry
        - check for inodes claiming duplicate blocks...
        - agno = 0
imap claims in-use inode 242000 is free, correcting imap
        - agno = 1
        - agno = 2
        ...
Phase 5 - rebuild AG headers and trees...
        - reset superblock counters...
Phase 6 - check inode connectivity...
        - ensuring existence of lost+found directory
        - traversing file system starting at / ... 
        - traversal finished ... 
        - traversing all unattached subtrees ... 
        - traversals finished ... 
        - moving disconnected inodes to lost+found ... 
disconnected inode 242000, moving to lost+found	
Phase 7 - verify and correct link counts...
Done

reboot と入力し、シングルユーザモードを終了してアプライアンスを再起動します。
XFS の修復によりパーティションが正常な動作に戻ったかどうかを評価します。
アプライアンスを再起動すると、パーティションが正常であれば Linux カーネルパニックをトリガしなくなります。
/nqxfs パーティションを修復する場合、そのパーティションでホストされている Vertica メトリックデータベースを再作成する必要があります。

XFS ファイル システム破損の評価および復旧

XFS ファイル システム破損の修復

XFS ファイルシステム破損の評価および復旧

XFS ファイルシステム破損の修復