アカウント名:
パスワード:
こういったのって、内部では秒をつかって表示・出力するときに時間とかに換算する場合が多いと思ってたけど、内部でも時間をつかってたのか
これ、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 HistoryNovember 2019 VDV10170 MR7 firmware release.
やっぱSSDもソフトウェア(ファームウェア)が鬼門ですね。# HDD時代でも有ったけどさ。
電源断して、次回起動時に時間を覚えていないと意味が無いので
時間単位でカウントということは稼働中は「前回と同じ値」となることの方が圧倒的に多そうで、そういう「時間を覚えておかないと困る」というシチュエーションがいまいち思い浮かばない。他のコメントにあるSMARTがらみで時間単位のカウントが必要というのは十分ありそうだけど、SMARTのためだけに保存している情報なら「データが喪失する」ほどSSD自体の動作に影響を与えるもんなんだろうか？とかモヤモヤしますね。
データはNAND上に有っても、ファームウェアが起動しないなら、結果的にSSDとしては機能しなくなります。ファームウェア更新のみ可能なモードとか、外部からコマンドを受け付けるまで起動すれば希望は有りますが。万が一管理領域自体が壊れて失われてしまうとNAND上に有るデータは断片化された状態(SSDは、NANDへの書き込み回数の平均化のために連続データも飛び飛びにされる)になり復旧は絶望的になります。他にも今時はデータをSSD内部で暗号化してから記録している奴が有るのですが、この鍵も管理領域破損時に一緒に飛んだとか、NAND上になくて、開封と同時に鍵が飛ぶ対タンパ仕様だと、完全に積みで「データは結果的に喪失」します。
気にしてるのはそこじゃなくて「(おそらくSMART用と思われる)稼働時間カウンタの値が不正なことが、ファームの動作に影響を与えるシチュエーションがいまいち思い浮かばない」なんですが。一時間単位のような粗いカウンタを参照する必要性があるの？ってとこ。
あれ？匿名になっちゃった。間違ってチェックボックスクリックしたのかな？
ほぼ解決済みのような気がしますが、異常データが入ってきたときにどうするかは設計方針によるかと思います。大前提として、ストレージに関しては、故障で止まるよりも、壊れたデータが読めた時の方が被害は拡大します。
有り得ない負数が入ってきた＝NANDメモリ等が致命的な障害を起こしたと判定して、それ以降読んだり・書き込んで状況を悪化させない設計というのも「アリ」だと思いますよ。管理エリアのデータが壊れた＝書き込めば無事かもしれないデータもどんどん失われるですからね。
ウェアレベリングとかは？フラッシュのデータ揮発防止用にあるブロックがどれくらいの時間移動していないかを管理するのに使っていたら、オーバーフローすることでウェアレベリングに異常をきたし、ライトするブロックの平均化がうまく行かなくなってフラッシュが短時間でぶっこわれてしまうとかはないかな？
疑問点は「なぜ稼働時間を計算しているのか分からない」(解決済み)と「なぜサブルーチンの一つが異常終了しただけで装置の異常動作が引き起こされるような設計が許容されるのか分からない」の2点かな?
なるほど、書き込み頻度が高いとこを見つけるのは回数だけ見れば十分だろうけど、頻度の低いとこを探すには経過時間を基準にした方がいいだろうし、精度が粗くても支障はない。だけど元にするカウンタがオーバーフローする可能性は見落としていたと。本当にそれが理由かはわからないけど、なんかありそうですね。
(すばらしい洞察)
もっと単純にスレッドセーフでもなんでもないRTOSだから起動しなくなるだけではないの
単純にintカウントのオーバーフロー対応をしていなくて、カウントがオーバーフローした結果、隣のメモリ領域にまであふれ出して上書きー＞上書きしたところがクリティカルな部分でコンロローラ全体アボン
みたいなあほな理由な気がする。
一瞬だけそれは考えたけど、最上位ビットによって書き込みサイズが変化するなんてのはわざわざそうする必要があるとき(UTFのような可変長エンコードとか)にするめんどくさい実装であって、そんなのをうっかり仕込んでしまったと考えるのはかなり無理があるので自分の中では却下した。
内部ではintでは無いのだろ。んでもってファームだからカリカリにチューニングしていたら、オーバーフローを見落としている所が有ったとか。
SSDってのはそれ自体がRTOSを積んだシングルボードコンピュータなので不正な設定データを読み込むと落ちるようなタスクがあった場合はブートループに陥っても不思議はない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
内部的に「時間」を使ってるのか (スコア:0)
こういったのって、内部では秒をつかって
表示・出力するときに時間とかに換算する場合が多いと思ってたけど、
内部でも時間をつかってたのか
Re:内部的に「時間」を使ってるのか (スコア:1)
これ、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時代でも有ったけどさ。
Re:内部的に「時間」を使ってるのか (スコア:1)
電源断して、次回起動時に時間を覚えていないと意味が無いので
時間単位でカウントということは稼働中は「前回と同じ値」となることの方が圧倒的に多そうで、そういう「時間を覚えておかないと困る」というシチュエーションがいまいち思い浮かばない。
他のコメントにあるSMARTがらみで時間単位のカウントが必要というのは十分ありそうだけど、SMARTのためだけに保存している情報なら「データが喪失する」ほどSSD自体の動作に影響を与えるもんなんだろうか？
とかモヤモヤしますね。
うじゃうじゃ
Re:内部的に「時間」を使ってるのか (スコア:1)
データはNAND上に有っても、ファームウェアが起動しないなら、結果的にSSDとしては機能しなくなります。
ファームウェア更新のみ可能なモードとか、外部からコマンドを受け付けるまで起動すれば希望は有りますが。
万が一管理領域自体が壊れて失われてしまうとNAND上に有るデータは断片化された状態(SSDは、NANDへの書き込み回数の平均化のために連続データも飛び飛びにされる)になり復旧は絶望的になります。
他にも今時はデータをSSD内部で暗号化してから記録している奴が有るのですが、この鍵も管理領域破損時に一緒に飛んだとか、NAND上になくて、開封と同時に鍵が飛ぶ対タンパ仕様だと、完全に積みで「データは結果的に喪失」します。
Re: (スコア:0)
気にしてるのはそこじゃなくて「(おそらくSMART用と思われる)稼働時間カウンタの値が不正なことが、ファームの動作に影響を与えるシチュエーションがいまいち思い浮かばない」なんですが。
一時間単位のような粗いカウンタを参照する必要性があるの？ってとこ。
Re:内部的に「時間」を使ってるのか (スコア:1)
あれ？匿名になっちゃった。
間違ってチェックボックスクリックしたのかな？
うじゃうじゃ
Re:内部的に「時間」を使ってるのか (スコア:1)
ほぼ解決済みのような気がしますが、異常データが入ってきたときにどうするかは設計方針によるかと思います。
大前提として、ストレージに関しては、故障で止まるよりも、壊れたデータが読めた時の方が被害は拡大します。
有り得ない負数が入ってきた＝NANDメモリ等が致命的な障害を起こしたと判定して、
それ以降読んだり・書き込んで状況を悪化させない設計というのも「アリ」だと思いますよ。
管理エリアのデータが壊れた＝書き込めば無事かもしれないデータもどんどん失われるですからね。
Re: (スコア:0)
ウェアレベリングとかは？
フラッシュのデータ揮発防止用にあるブロックがどれくらいの時間移動していないかを管理するのに使っていたら、オーバーフローすることでウェアレベリングに異常をきたし、ライトするブロックの平均化がうまく行かなくなってフラッシュが短時間でぶっこわれてしまうとかはないかな？
Re: (スコア:0)
疑問点は「なぜ稼働時間を計算しているのか分からない」(解決済み)と「なぜサブルーチンの
一つが異常終了しただけで装置の異常動作が引き起こされるような設計が許容されるのか分からない」
の2点かな?
Re:内部的に「時間」を使ってるのか (スコア:1)
なるほど、書き込み頻度が高いとこを見つけるのは回数だけ見れば十分だろうけど、頻度の低いとこを探すには経過時間を基準にした方がいいだろうし、精度が粗くても支障はない。
だけど元にするカウンタがオーバーフローする可能性は見落としていたと。
本当にそれが理由かはわからないけど、なんかありそうですね。
(すばらしい洞察)
うじゃうじゃ
Re: (スコア:0)
もっと単純にスレッドセーフでもなんでもないRTOSだから起動しなくなるだけではないの
Re: (スコア:0)
単純にintカウントのオーバーフロー対応をしていなくて、
カウントがオーバーフローした結果、隣のメモリ領域にまであふれ出して上書きー＞上書きしたところがクリティカルな部分でコンロローラ全体アボン
みたいなあほな理由な気がする。
Re:内部的に「時間」を使ってるのか (スコア:1)
一瞬だけそれは考えたけど、最上位ビットによって書き込みサイズが変化するなんてのはわざわざそうする必要があるとき(UTFのような可変長エンコードとか)にするめんどくさい実装であって、そんなのをうっかり仕込んでしまったと考えるのはかなり無理があるので自分の中では却下した。
うじゃうじゃ
Re: (スコア:0)
内部ではintでは無いのだろ。
んでもってファームだからカリカリにチューニングしていたら、オーバーフローを見落としている所が有ったとか。
Re: (スコア:0)
SSDってのはそれ自体がRTOSを積んだシングルボードコンピュータなので
不正な設定データを読み込むと落ちるようなタスクがあった場合はブートループに陥っても不思議はない