SORA L2 Blockchain – FromHDDtoSSD S.M.A.R.T.

S.M.A.R.T.の利用方法模索

自己診断機能“S.M.A.R.T.”(Self-Monitoring Analysis and Reporting Technology)をドライブから取得して、 その変化を計算することにより、事前に故障を「予測すること」が、できるとされております。そこで、S.M.A.R.T.単独では厳しい予測を、 複数の調査結果と組み合わせる事により通知から予測する試みを１０年以上、行ってきました。 

ストレージ故障予測: スキャンを組み合わせてドライブ故障を予測します。24時間継続のサーバ系に最適な機能です。

二通りの故障予測をご提供

S.M.A.R.T.数値変動グラフ: 数日分(約7日)の変動を記録しております。

• グラフ内部をクリックすると、現在値、データに関しまして、その表示を切り替えることができます。
• スキャンA、スキャンB、解析結果(左下グラフ)：独自の故障予測スキャンの結果を表示しております。
• 中央にある緑の線が中央に安定すれば正常、上下に振れてブルーゾーンを超えると、異常判定になります。
• 状態範囲の「レッドゾーン」に入った場合は、ドライブ換装をお勧めいたします。
• 再描写：各グラフを再描写します。
• 再解析：故障予測の演算部に再解析を促すキューを投げます。

S.M.A.R.T.では処理できないエラー・故障が多数存在することが判明いたしました。そこで各ドライブが確実に状況を出さなければならないコマンドで予測する方式を独自に開発いたしました。これを「故障予測スキャン」と名付けました。

技術パートナー様およびこの試みに賛同いただいたユーザ様のご協力 深く感謝いたします。その故障個所・不良セクタの種類・不良セクタの分布・故障発生前後の状況など 壊れやすい状況・アクション・内容を整理したうえソフトウェアにいたしました。

S.M.A.R.T.コンセンサス系: 低負荷でしっかり予測できます。普段のご利用に最適です。

ビッグデータを利用してドライブの故障予測を実施いたします。 S.M.A.R.T.およびビッグデータ以外に別の検査が必要な場合はそれを追加検査して総合判断いたします。 ストレージ故障予測では常駐的なスキャンを必要としますので常に常駐させる必要があります。しかし、こちらは常駐不要です。 負荷も軽いゆえ普段のご利用にはこちらの機能をご活用ください。

S.M.A.R.T.の状態変化については以下に従います。 ドライブの状態により判定が「180度異なる」ため、これがS.M.A.R.T.の難点です。 S.M.A.R.T.が動きましてバックアップを指示されても、すでに手遅れな場合が多いのはこのためです。

S.M.A.R.T.による予測の典型的な失敗例

S.M.A.R.T.では見抜けない物理障害をご紹介いたします。 データを損失しますので注意が必要となります。現在の8.0TB – 24TB級ドライブでもよく拝見しております。

S.M.A.R.T.の取得:
通常の読み書きとは「別」に存在するデータ

数字が並んでおりますが、あまり気にしないでください。この場合、一般的なS.M.A.R.T.予測ソフトウェアでは間違いなく良好を示します。 さて、この「良好」は本当でしょうか。そこで、このドライブにアクセスいたしまして、実際にデータを読み出してみましょう。

Windowsより読み取ろうとした結果エラーが発生

エラーが発生いたしました。データへのアクセス失敗です。このようなエラーについては、ソフトウェア的な破損ではなく物理的な破損の方が遥かに多いです。FATやMFTが、読み書き不能セクタで壊れた場合は物理的なエラーで読めないという流れになります。これらは症状が断定できないうえ、このエラーをすぐに「論理障害」と決め付けてはいけません。ここでFromHDDtoSSDの「完全スキャン」を実行いたします。

上側のグリーンについては検査して良好だった点を示しております。しかしこれはあくまでも「不良セクタがない」事を示しているのみとなります。「検査系ソフトウェア」で調査できるのはここまでです。 しかしこれでは全くの不十分です。下部の「動作安定度」の指標が非常に乱れております。こちらはグラフが「一直線」になれば正常で大きく乱れた場合は動作系統に異常があります。このドライブは物理的に壊れておりまして修理はできません。なおさら論理障害ではありません。

バックアップは、読み出せるかどうか時々でも良いのでご確認ください。実はそのバックアップ先が機能していなかったという場合を多くうかがいました。ドライブは「書き込み側」よりも「読み込み側」が壊れやすい性質となっております。そのため書き込み専門となってしまったバックアップ先については書き込めていないのに正常の通知が出てしまいます。これが要因で「読み込み側」が壊れても即時にエラーを出すこともなく曖昧に動作し続けてしまいます。読み込ませてエラーのセクタが検出され、そこではじめて「エラー」が返されます。それまでは正常な動作をふるまいます。 これが理由で書き込める状態でも「読み込める」とは限りません。これが……、「バックアップ損失」の主な原因となります。