スラドこの議論は賞味期限が切れたので、アーカイブ化されています。新たにコメントを付けることはできません。(5854)これ、HPE限定なのか、DELLやらOEM元の他社製品でもアップデート来るんですかね。時間を使うのは、電源断して、次回起動時に時間を覚えていないと意味が無いので、データ保存したけど、隣のデータ壊したとか、チェックサム異常でSSDのファームが起動途中で止まるとか、A/B面あって、不整合検出して止まったとかいったシナリオが有ると思います。[it.srad.jp]再び。m4は電断してリブートして更新したらデータは残ってたので、それより悲惨か。通電時間カウント回りは陥りやすいのか、Intelも1700時間で死亡やらかしてたり。(7374)電源断して、次回起動時に時間を覚えていないと意味が無いので時間単位でカウントということは稼働中は「前回と同じ値」となることの方が圧倒的に多そうで、そういう「時間を覚えておかないと困る」というシチュエーションがいまいち思い浮かばない。他のコメントにあるSMARTがらみで時間単位のカウントが必要というのは十分ありそうだけど、SMARTのためだけに保存している情報なら「データが喪失する」ほどSSD自体の動作に影響を与えるもんなんだろうか?とかモヤモヤしますね。(5854)データはNAND上に有っても、ファームウェアが起動しないなら、結果的にSSDとしては機能しなくなります。ファームウェア更新のみ可能なモードとか、外部からコマンドを受け付けるまで起動すれば希望は有りますが。万が一管理領域自体が壊れて失われてしまうとNAND上に有るデータは断片化された状態(SSDは、NANDへの書き込み回数の平均化のために連続データも飛び飛びにされる)になり復旧は絶望的になります。他にも今時はデータをSSD内部で暗号化してから記録している奴が有るのですが、この鍵も管理領域破損時に一緒に飛んだとか、NAND上になくて、開封と同時に鍵が飛ぶ対タンパ仕様だと、完全に積みで「データは結果的に喪失」します。(#3726300)気にしてるのはそこじゃなくて「(おそらくSMART用と思われる)稼働時間カウンタの値が不正なことが、ファームの動作に影響を与えるシチュエーションがいまいち思い浮かばない」なんですが。一時間単位のような粗いカウンタを参照する必要性があるの?ってとこ。日記あれ?匿名になっちゃった。(#3726833)ほぼ解決済みのような気がしますが、異常データが入ってきたときにどうするかは設計方針によるかと思います。大前提として、ストレージに関しては、故障で止まるよりも、壊れたデータが読めた時の方が被害は拡大します。有り得ない負数が入ってきた=NANDメモリ等が致命的な障害を起こしたと判定して、それ以降読んだり・書き込んで状況を悪化させない設計というのも「アリ」だと思いますよ。管理エリアのデータが壊れた=書き込めば無事かもしれないデータもどんどん失われるですからね。日記なるほど、書き込み頻度が高いとこを見つけるのは回数だけ見れば十分だろうけど、頻度の低いとこを探すには経過時間を基準にした方がいいだろうし、精度が粗くても支障はない。元にするカウンタがオーバーフローする可能性は見落としていたと。本当にそれが理由かはわからないけど、なんかありそうですね。Coward単純にintカウントのオーバーフロー対応をしていなくて、カウントがオーバーフローした結果、隣のメモリ領域にまであふれ出して上書きー>上書きしたところがクリティカルな部分でコンロローラ全体アボンみたいなあほな理由な気がする。一瞬だけそれは考えたけど、最上位ビットによって書き込みサイズが変化するなんてのはわざわざそうする必要があるとき(UTFのような可変長エンコードとか)にするめんどくさい実装であって、そんなのをうっかり仕込んでしまったと考えるのはかなり無理があるので自分の中では却下した。Coward内部ではintでは無いのだろ。もってファームだからカリカリにチューニングしていたら、オーバーフローを見落としている所が有ったとか。多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。service.閉じるスラド処理中...。