TrueNASからストレージ関連のアラートが届きました。画面には「Pool state is ONLINE」と表示されています。
ONLINEなら問題ないようにも見えますが、現在の状態だけで「何も起きていない」とは断定できません。一方、アラートが出たという理由だけで、すぐにSSD故障と決めつけることもできません。
そこで今回は、次の順番で状態を切り分けました。
- アラート内容を確認する
- boot-poolの状態と構成を確認する
- 対象SSDを特定する
- SMART情報を確認する
- SMART Short self-testを実施する
- ZFS側の状態を再確認する
- 今後の対応を判断する
この記事は故障原因を特定した記録ではありません。TrueNASでストレージ系アラートが出たときに、私が実際にどのような順番で調査したかをまとめたものです。
TrueNASから突然アラートが届いた
最初に確認したのが、TrueNASのアラート画面です。
今回のアラートではpool stateがONLINEと表示されていました。ただし、これは確認した時点のpool状態を示すものです。この表示だけを根拠に、アラート発生前後を含めて異常がなかったとは判断しませんでした。
TrueNAS公式のDrive Troubleshooting Flowchartでも、ドライブやZFSの問題は症状に応じて系統的に確認する流れが示されています。私もまず交換作業へ進むのではなく、ZFSとSMARTの情報を順番に確認することにしました。
poolの現在状態を確認する
まずはTrueNASの画面から、問題が示されたpoolの現在状態を確認しました。
確認時点のboot-poolはONLINEでした。
ここで大切なのは、ONLINEを「現在、ZFSから見てpoolが利用可能な状態」として受け取り、それ以上の意味を勝手に加えないことです。過去に一時的なイベントがあったのか、アラートが何を契機に発生したのかは、ONLINEの表示だけでは確定できません。
boot-poolの構成を確認する
続いて、boot-poolを構成しているデバイスを確認しました。
今回の環境では、TrueNAS OS用のboot-poolを2台の128GB SPCC SSDでmirror構成にしています。
初心者向けに簡単に分けると、次のようになります。
- boot-pool：TrueNAS OSやboot environmentを保存するpool
- データpool：共有フォルダーやアプリのデータなどを保存するpool
TrueNAS公式のBoot Pool Managementでも、boot-poolはTrueNAS OSを保存するZFS poolとして説明されています。データpoolとは役割が異なるため、どのpoolでアラートが出たのかを最初に区別しておくことが重要です。
対象SSDを特定する
SMARTを確認する前に、boot-poolのどのSSDを調べるのかを特定しました。
デバイス名は環境によって異なります。別の環境でこの記事のコマンドを試す場合は、/dev/sdXをそのまま入力せず、TrueNASの画面やzpool statusなどで自分の環境のデバイス名を必ず確認してください。
なお、掲載画像ではpool名、シリアル番号など、記事の説明に不要な個人環境情報を伏せています。
SMART情報を確認する
対象SSDを特定した後、smartctlでSMART情報を確認しました。以下の/dev/sdXは例なので、実際のデバイス名へ置き換えます。
sudo smartctl -a /dev/sdX
今回確認した2台のSSDは、どちらも次の結果でした。
SMART overall-health self-assessment test result: PASSED
ただし、PASSEDは「今後も故障しない」という保証ではありません。今回の調査時点で、SMARTの総合判定がPASSEDだったという確認結果として扱いました。
SMARTのVALUEとRAW_VALUEを混同しない
SMART属性を見るときは、VALUE、WORST、THRESH、RAW_VALUEを混同しないよう注意が必要です。
例えばReallocated_Sector_CtでVALUE=100と表示されても、それだけで「不良セクタが100個ある」という意味にはなりません。VALUEは一般に正規化された値であり、実際のカウントに相当する情報がRAW_VALUE側に示される場合があります。
さらに、Vendor Specific Attributeはメーカーや機種によって実装・解釈が異なります。属性名や数字を一つだけ取り出して、故障原因まで断定しないようにしました。
SMART Short self-testを実施する
静的なSMART情報だけでなく、SSD自身のShort self-testも実施しました。
テスト開始コマンドは次のとおりです。
sudo smartctl -t short /dev/sdX
表示された待ち時間が経過してから、self-test logを確認します。
sudo smartctl -l selftest /dev/sdX
TrueNAS 25.10以降では、ZFSによるリアルタイムの障害検知と、TrueNAS Middlewareによる90分ごとのSMARTポーリングがDrive Health Managementの基本です。Community Editionでは、必要に応じてsmartctlによる手動のShort / Long testを追加できます。TrueNAS公式では、Short testは短時間の診断、Long testはドライブ全体をより詳しく検査する手動テストとして案内されています。
片側のSSDでは、self-test logに次の結果が記録されました。
Completed without error
もう片側のSSDでは、Short self-testの開始コマンド自体は受理されましたが、確認したself-test logにはテスト履歴が記録されない挙動でした。
このSSDもSelf-test supportedと表示されていましたが、今回の結果だけから「SSD異常」「TrueNASの不具合」「smartctlの問題」などと原因を断定することはできません。記事には、実機でその挙動を確認したという事実だけを残します。
ZFS側を再確認する
SMARTの確認後、ZFS側からboot-poolの状態を再確認しました。
sudo zpool status -v boot-pool
環境によっては権限や実行方法が異なる場合があります。今回は必要なコマンドにsudoを付けて実行しています。
確認結果は次のとおりでした。
- boot-pool：ONLINE
- mirrorを構成する2デバイス：どちらもONLINE
- READ：0
- WRITE：0
- CKSUM：0
errors: No known data errors- 直近のboot-pool scrub：0 errors
TrueNASのBoot Pool Status画面でも、boot-poolと構成デバイスの状態に加え、read・write・checksum errorを確認できます。コマンドではzpool status -vを使うことで、同じようにZFS側の状態を詳しく確認できます。
scrubとSMART self-testは確認対象が異なる
ZFS scrubとSMART self-testは、どちらもストレージ確認に使いますが、同じものではありません。
- ZFS scrub：pool内のデータを読み取り、ZFSのチェックサムを使って整合性を確認する
- SMART self-test：ドライブ自身の診断機能を使ってデバイスを検査する
TrueNAS公式のpool管理資料でも、scrubはpoolのデータ整合性チェックとして案内されています。そのため、片方だけで判断せず、ZFSとSMARTの両方から確認しました。
Long SMARTは今回は実施しなかった
2台ともExtended / Long self-testに対応していることは確認しました。対応状況や推定所要時間は、次のコマンドで確認できます。
sudo smartctl -c /dev/sdX
今回表示されたLong self-testの推定所要時間は、片側が約90分、もう片側が約30分でした。
Long self-testを開始する場合のコマンドは次のとおりです。
sudo smartctl -t long /dev/sdX
ただし、今回はこのコマンドを実行していません。
判断材料は次の4点です。
- boot-poolがONLINE
- ZFSのREAD・WRITE・CKSUMエラーがすべて0
- 両SSDのSMART overall-healthがPASSED
- Short self-testを含む今回の確認で、明確な故障を示す結果が見つからなかった
Long testはShort testより広い範囲を検査しますが、TrueNAS公式ドキュメントでも、テスト実行中はドライブ性能へ影響する可能性があるため、使用量の少ない時間帯に実行し、scrubなどの負荷が高い処理と重ねないことが推奨されています。
今回は追加負荷をかけて直ちにLong testを行う段階ではないと判断し、再発時の追加診断手段として残しました。
今回の結論：交換ではなく継続監視とした
今回の調査時点では、明確なSSD故障を示す結果は確認できませんでした。そのため、SSDの即時交換は行わず、継続監視としました。
ただし、これは「SSDが故障していない」と確定した意味ではありません。今回の調査ではアラート発生原因そのものまでは特定できておらず、SSD本体以外の要因を含めて原因候補を切り分けるところまでは実施していません。
そのため、誤検知、接続系、電源系、SSD自体の異常など、考え得る個別要因のどれかを今回の原因として挙げることは避けます。
今回の経験から、TrueNASでストレージ系アラートが出たときは、次のように考えるのがよさそうです。
- 「アラートが出た＝即ディスク交換」と決めつけない
- 「ONLINEに戻った＝完全に問題なし」とも決めつけない
- poolと対象ディスクを特定する
- ZFSの状態、エラーカウンター、scrub結果を確認する
- SMARTの総合判定とself-test結果を確認する
- 確認済みの事実と推測を分けて記録する
同様のアラートが再発した場合は、アラート発生時刻や内容を保存したうえで、Extended / Long SMART self-testまで実施し、今回の結果と比較する方針です。
コメント