パスワードを忘れた? アカウント作成
14061970 story
ストレージ

HPEのサーバーやストレージで使われているSSDで不具合、SHRT_MAX+1時間の稼働でデータ喪失 70

ストーリー by hylom
どうしてこうなった 部門より

エンタープライズ向け製品を手がけるHewlett Packard Enterprise(HPE)のサーバーやストレージで使われている特定のSSDで、稼働時間が32768時間(約3年270日8時間)を超えるとデータが喪失する不具合が確認されているとのこと(PC Watch)。

ファームウェアが原因とのことで、「32768」はshort intの最大値である32767を超えた値であることから、SSDの内部でのデータの取り扱いに何らかのミスがあったのではないかと見られている。HPEはこれに対応するためのファームウェアを配布しており、利用者に対してはすぐの適用が呼びかけられている。

  • 対象SSD一覧に掲載されている「VK007680JWSSU」でぐぐるとVMware Compatibility Guideの「モデル:HPE 7.68TB SAS RI SFF SC DS SSD [vmware.com]」が出てくるわけなんですが、そこには「ベンダーID: Samsung」「シリーズ: PM1643」という文字列が

    はたしてこのバグはhpe向けカスタムモデルのみなのか、それとも自社ブランドのPM1643や、他社…例えばLenovo向けのPM1643 [lenovopress.com]にも適用される話なのか
    続報はどうなるかな

    ここに返信
    • 調べてみましたが、ベンダーが HPと書かれているeMLCのものもSamsung製でした (・ω・)

      HPD8に不具合と書いてるので、HP向けにカスタムで作ったサムスン電子のファームの問題で、他社だと同じハードでも問題でなかったりするのでは…?(PM1643 量産開始したのが 2018年、HPD9に切り替わったのが 2015年後半ごろっぽいので HPE だけとか)

    • この(HP曰く)SSDの不具合で、SSDのベアドライブ自体にアクセスできなくなるのか、SSDが正常なデータを返さなくなることで、エンクロージャが誤動作するのか。
      後者なら他社への波及は最小限になるのではないでしょうか。

      後者だと例えばこんな感じでしょうか。詳報出るんでしょうかね。
      ・SSDがSMARTでおかしな値を返す
      ・エンクロージャのファームウェアがSSD故障と判断して切り離し
      ・ホットスペアにリビルド中に別のSSDも次々とエラー
      ・結果としてマルチデッド

    • by Anonymous Coward
      やっぱサムソンは避けるのが正解だな。
  • by yoshimo (15798) on 2019年12月05日 13時17分 (#3726578)

    サーバ用途でもSSDが普及してきてますが、SSDの場合にRAID1とか5にする必要性はあまり無いような気がするんですけどどうなんでしょう。

    ハードディスクの場合、物理的に壊れるリスクが高いのでRAIDを組むのが一般的ですが、SSDがハードウェア的に壊れる確率ってそれほど高くないのでは。

    ここに返信
    • by nekopon (1483) on 2019年12月05日 14時40分 (#3726633) 日記
      HDDは「徐々に」壊れるのですがSSDは「突然一度に」壊れる、そうです。
      // 速度的なものでRAID化する意味はあるのですが
  • by Anonymous Coward on 2019年12月04日 16時56分 (#3726096)

    こういったのって、内部では秒をつかって
    表示・出力するときに時間とかに換算する場合が多いと思ってたけど、
    内部でも時間をつかってたのか

    ここに返信
    • これ、HPE限定なのか、DELLやらOEM元の他社製品でもアップデート来るんですかね。

      時間を使うのは、電源断して、次回起動時に時間を覚えていないと意味が無いので、データ保存したけど、隣のデータ壊したとか、
      チェックサム異常でSSDのファームが起動途中で止まるとか、A/B面あって、不整合検出して止まったとかいったシナリオが有ると思います。

      なんというか、m4の悲劇 [it.srad.jp]再び。
      m4は電断してリブートして更新したらデータは残ってたので、それより悲惨か。

      通電時間カウント回りは陥りやすいのか、Intelも1700時間で死亡やらかしてたり。 [intel.com]
      全然関係ないけど、1700時間で死んだIntelのDC向けSSDに修正ファーム新しいのが来てる。 [intel.com]

      Intel® Solid State Drive DC P4510 and P4610 and P4511 Series Revision History
      November 2019 VDV10170 MR7 firmware release.

      やっぱSSDもソフトウェア(ファームウェア)が鬼門ですね。
      # HDD時代でも有ったけどさ。

      • 電源断して、次回起動時に時間を覚えていないと意味が無いので

        時間単位でカウントということは稼働中は「前回と同じ値」となることの方が圧倒的に多そうで、そういう「時間を覚えておかないと困る」というシチュエーションがいまいち思い浮かばない。
        他のコメントにあるSMARTがらみで時間単位のカウントが必要というのは十分ありそうだけど、SMARTのためだけに保存している情報なら「データが喪失する」ほどSSD自体の動作に影響を与えるもんなんだろうか?
        とかモヤモヤしますね。

        --
        うじゃうじゃ
        • データはNAND上に有っても、ファームウェアが起動しないなら、結果的にSSDとしては機能しなくなります。
          ファームウェア更新のみ可能なモードとか、外部からコマンドを受け付けるまで起動すれば希望は有りますが。
          万が一管理領域自体が壊れて失われてしまうとNAND上に有るデータは断片化された状態(SSDは、NANDへの書き込み回数の平均化のために連続データも飛び飛びにされる)になり復旧は絶望的になります。
          他にも今時はデータをSSD内部で暗号化してから記録している奴が有るのですが、この鍵も管理領域破損時に一緒に飛んだとか、NAND上になくて、開封と同時に鍵が飛ぶ対タンパ仕様だと、完全に積みで「データは結果的に喪失」します。

          • by Anonymous Coward

            気にしてるのはそこじゃなくて「(おそらくSMART用と思われる)稼働時間カウンタの値が不正なことが、ファームの動作に影響を与えるシチュエーションがいまいち思い浮かばない」なんですが。
            一時間単位のような粗いカウンタを参照する必要性があるの?ってとこ。

            • あれ?匿名になっちゃった。
              間違ってチェックボックスクリックしたのかな?

              --
              うじゃうじゃ
              • ほぼ解決済みのような気がしますが、異常データが入ってきたときにどうするかは設計方針によるかと思います。
                大前提として、ストレージに関しては、故障で止まるよりも、壊れたデータが読めた時の方が被害は拡大します。

                有り得ない負数が入ってきた=NANDメモリ等が致命的な障害を起こしたと判定して、
                それ以降読んだり・書き込んで状況を悪化させない設計というのも「アリ」だと思いますよ。
                管理エリアのデータが壊れた=書き込めば無事かもしれないデータもどんどん失われるですからね。

              • by Anonymous Coward

                ウェアレベリングとかは?
                フラッシュのデータ揮発防止用にあるブロックがどれくらいの時間移動していないかを管理するのに使っていたら、オーバーフローすることでウェアレベリングに異常をきたし、ライトするブロックの平均化がうまく行かなくなってフラッシュが短時間でぶっこわれてしまうとかはないかな?

              • なるほど、書き込み頻度が高いとこを見つけるのは回数だけ見れば十分だろうけど、頻度の低いとこを探すには経過時間を基準にした方がいいだろうし、精度が粗くても支障はない。
                だけど元にするカウンタがオーバーフローする可能性は見落としていたと。
                本当にそれが理由かはわからないけど、なんかありそうですね。

                (すばらしい洞察)

                --
                うじゃうじゃ
        • by Anonymous Coward

          SSDってのはそれ自体がRTOSを積んだシングルボードコンピュータなので
          不正な設定データを読み込むと落ちるようなタスクがあった場合はブートループに陥っても不思議はない

    • by Anonymous Coward

      カウンタのオーバーフローを避けようとすると変数のサイズを上げるかカウンタの精度を下げるかの二択。
      でカウンタの精度は落としたくないので一時間未満は秒一時間以上を時の二変数体制にしたんでしょう。
      ウインドウズの可動時間計測の実装よりはスマートな気がしますけど。
      次は32768日稼働すると落ちるようになる?

    • by Anonymous Coward

      総稼働時間をSMARTに入るように(int)にキャストしたんじゃないの

    • by Anonymous Coward

      HDD/SSDのSMART(Self-Monitoring, Analysis and Reporting Technology)では、「通電時間」とか時間単位でカウントする機能を持っていたりするので。

  • by Anonymous Coward on 2019年12月04日 16時59分 (#3726099)

    Cだとshort intの最大値はSHORT_MAXで、具体的な値は処理系依存だったような…

    ここに返信
    • by Anonymous Coward

      SSDコントローラに組み込まれてるCPUコアって、だいたいARMだとおもう
      これなら最低32bitはあるはず

      なのでSHORT_MAXは20億はあるはず

      わざわざ明示的にint16を使ったのか、
      それともCPUコア以外の部分で16bit実装してたのか

      • by Anonymous Coward

        SSDコントローラに組み込まれてるCPUコアって、だいたいARMだとおもう
        これなら最低32bitはあるはず

        なのでSHORT_MAXは20億はあるはず

        どういう理屈??

        • by Anonymous Coward

          INT_MAXと取り違えているのに一票。
          Cの規格上だと、SHRT_MAXもINT_MAXも「32767(2^15-1)以上」ってことになっているけど、intが64bitになったってSHRT_MAXが32767以外になっている処理系に出会ったことはないなぁ。

          # WORDとかDWORDとかtypedefしているのをメンテすることあるけど、これはほんと止めて欲しい。サイズも符号の有無も判らなくて、いちいちtypedefしているところを探す羽目になる。最悪なのは、同一プロジェクト内で何にtypedefしているかバラバラなこと。

          • by Anonymous Coward on 2019年12月04日 20時38分 (#3726221)

            ひょっとしてこれがあるかな?
            SATAのコマンドフレームとしてWORD=32bitで表現しているので設計者は32bitあると思い込んでいたが、実際にWORDをtypedefしていたファイルは8bitマイコン時代から使い回していたシロモノでWORD=16bitだったとか。

      • by Anonymous Coward

        SHORT_MAXって何ですか?
        というのはおいておき、GCCもVCもSHRT_MAXが32767で、INT_MAXが2147483647の実装だと思うのだが。

    • by Anonymous Coward

      今の時代、処理系依存するような型をクリティカルな場所で使用するなよぉ。
      stdint.h の存在を知らなかったとはいはせない。

      それともやはり、アセンブラで書いているとか。

      • by Anonymous Coward

        stdint.hも処理系依存なんだが・・

        • by Anonymous Coward

          処理系依存と言っても int32_t が使えて実は16bitなんて事はありえないでしょ。
          定義されてない場合はあるにしても。

  • by Anonymous Coward on 2019年12月04日 17時10分 (#3726104)

    気になる...
     
    # パッチ後は65535時間に延長されるだけだったりして...

    ここに返信
    • 意表をついて「32767日」だったり。
      ドヤ顔で「耐用時間が24倍になりました!!」

    • by Anonymous Coward

      > # パッチ後は65535時間に延長されるだけだったりして...

      7年超になれば、実質的に問題なくなりそう。
      その前にどこか別のところが壊れるから。

      • by Anonymous Coward

        もともと7年超でデータ消去して強制的に買い替えさせる設計だったけど
        signedとunsigned間違えて前倒しになったのか?

      • by Anonymous Coward

        インテルのSSDを5万時間使ってもまだ壊れてないから65535時間は十分あり得る時間かと

    • by Anonymous Coward

      32767時間59分59秒みたいに32767時間台いっぱい、つまりほぼ23768時間ちょうどまでってことでしょうね。
      桁上げ先の1つ上のbitには何のデータが陣取ってるんだろう…何かのフラグなんだろうか…HPEが崩壊するフラグ…

  • by Anonymous Coward on 2019年12月04日 17時16分 (#3726111)

    RAIDにして「1個や2個壊れても大丈夫!」と思ってたら、全部が一斉に壊れるとなると・・・

    ここに返信
    • by Anonymous Coward on 2019年12月05日 1時01分 (#3726330)

      RAIDにして「1個や2個壊れても大丈夫!」と思ってたら、全部が一斉に壊れるとなると・・・

      RAID 0 < ( ´∀`)人(´∀` )ナカーマ

    • by Anonymous Coward

      RAID(1とか5)で同じロットのディスクを使ってはならんのだ。

      • by Anonymous Coward

        稼働時間が問題なわけだから、この問題に関してはロット違ってもあんまり意味ないような…

      • by Anonymous Coward

        それがやりたかったら装置自体を多重化してくださいね

        • by Ryo.F (3896) on 2019年12月04日 20時47分 (#3726225) 日記

          「装置」って何のこと?
          RAIDコントローラ?
          電源?
          筐体?
          いずれにせよ、多重化は可能ですが、金はかかるわけです。
          しかし、ディスクのロットを違えることにかかる金は、それに比べれば非常に小さい。
          ならば、費用対効果を考えて、ディスクのロットだけ変える、という判断があってもヘンではありませんよ。

          • by Anonymous Coward

            ドヤ顔で「プロはディスク玉のメーカーやロットを変える!」とか主張する人がたまにいるけど
            ストレージベンダーでもフォルトトレランスシステムベンダーでもそんなことやってないw

            EMCとかStratusの中開けたら普通に同ロット同メーカーのディスク玉並んでるぞ。
            予備交換でズレてることはあるけど。

            • by Ryo.F (3896) on 2019年12月06日 17時31分 (#3727528) 日記

              効果が限定的だ、と考えて、やらない、という選択肢もまたヘンではありません。
              どっちもあり得る、という話をしています。

              ところで、「予備交換」はあまり聞かないですね。
              「予防交換」って言いません?

        • by Anonymous Coward

          同時稼働したら同じなので、半年後に予備をさらに買って入れ替えないと。
          テスト環境を本番に格上げ、バックアップを追加購入な環境なら猶予があるかもしれない。

      • by Anonymous Coward

        ロットが違えば助かると確定するわけでもないし、その考え方は中途半端。
        そもそもRAID5はやめよう。

    • by Anonymous Coward

      データ復旧業者もお手上げな壊れ方するらしいね。
      まぁもともとSSDは復旧が難しいらしいが。

typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...