アカウント名:
パスワード:
こういったのって、内部では秒をつかって表示・出力するときに時間とかに換算する場合が多いと思ってたけど、内部でも時間をつかってたのか
これ、HPE限定なのか、DELLやらOEM元の他社製品でもアップデート来るんですかね。
時間を使うのは、電源断して、次回起動時に時間を覚えていないと意味が無いので、データ保存したけど、隣のデータ壊したとか、チェックサム異常でSSDのファームが起動途中で止まるとか、A/B面あって、不整合検出して止まったとかいったシナリオが有ると思います。
なんというか、m4の悲劇 [it.srad.jp]再び。m4は電断してリブートして更新したらデータは残ってたので、それより悲惨か。
通電時間カウント回りは陥りやすいのか、Intelも1700時間で死亡やらかしてたり。 [intel.com] 全然関係ないけど、1700時間で死んだIntelの [intel.com]
電源断して、次回起動時に時間を覚えていないと意味が無いので
時間単位でカウントということは稼働中は「前回と同じ値」となることの方が圧倒的に多そうで、そういう「時間を覚えておかないと困る」というシチュエーションがいまいち思い浮かばない。他のコメントにあるSMARTがらみで時間単位のカウントが必要というのは十分ありそうだけど、SMARTのためだけに保存している情報なら「データが喪失する」ほどSSD自体の動作に影響を与えるもんなんだろうか？とかモヤモヤしますね。
データはNAND上に有っても、ファームウェアが起動しないなら、結果的にSSDとしては機能しなくなります。ファームウェア更新のみ可能なモードとか、外部からコマンドを受け付けるまで起動すれば希望は有りますが。万が一管理領域自体が壊れて失われてしまうとNAND上に有るデータは断片化された状態(SSDは、NANDへの書き込み回数の平均化のために連続データも飛び飛びにされる)になり復旧は絶望的になります。他にも今時はデータをSSD内部で暗号化してから記録している奴が有るのですが、この鍵も管理領域破損時に一緒に飛んだとか、NAND上になくて、開封と同時に鍵が飛ぶ対タンパ仕様だと、完全に積みで「データは結果的に喪失」します。
気にしてるのはそこじゃなくて「(おそらくSMART用と思われる)稼働時間カウンタの値が不正なことが、ファームの動作に影響を与えるシチュエーションがいまいち思い浮かばない」なんですが。一時間単位のような粗いカウンタを参照する必要性があるの？ってとこ。
あれ？匿名になっちゃった。間違ってチェックボックスクリックしたのかな？
ほぼ解決済みのような気がしますが、異常データが入ってきたときにどうするかは設計方針によるかと思います。大前提として、ストレージに関しては、故障で止まるよりも、壊れたデータが読めた時の方が被害は拡大します。
有り得ない負数が入ってきた＝NANDメモリ等が致命的な障害を起こしたと判定して、それ以降読んだり・書き込んで状況を悪化させない設計というのも「アリ」だと思いますよ。管理エリアのデータが壊れた＝書き込めば無事かもしれないデータもどんどん失われるですからね。
もっと単純にスレッドセーフでもなんでもないRTOSだから起動しなくなるだけではないの
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
内部的に「時間」を使ってるのか (スコア:0)
こういったのって、内部では秒をつかって
表示・出力するときに時間とかに換算する場合が多いと思ってたけど、
内部でも時間をつかってたのか
Re: (スコア:1)
これ、HPE限定なのか、DELLやらOEM元の他社製品でもアップデート来るんですかね。
時間を使うのは、電源断して、次回起動時に時間を覚えていないと意味が無いので、データ保存したけど、隣のデータ壊したとか、
チェックサム異常でSSDのファームが起動途中で止まるとか、A/B面あって、不整合検出して止まったとかいったシナリオが有ると思います。
なんというか、m4の悲劇 [it.srad.jp]再び。
m4は電断してリブートして更新したらデータは残ってたので、それより悲惨か。
通電時間カウント回りは陥りやすいのか、Intelも1700時間で死亡やらかしてたり。 [intel.com]
全然関係ないけど、1700時間で死んだIntelの [intel.com]
Re: (スコア:1)
電源断して、次回起動時に時間を覚えていないと意味が無いので
時間単位でカウントということは稼働中は「前回と同じ値」となることの方が圧倒的に多そうで、そういう「時間を覚えておかないと困る」というシチュエーションがいまいち思い浮かばない。
他のコメントにあるSMARTがらみで時間単位のカウントが必要というのは十分ありそうだけど、SMARTのためだけに保存している情報なら「データが喪失する」ほどSSD自体の動作に影響を与えるもんなんだろうか？
とかモヤモヤしますね。
うじゃうじゃ
Re: (スコア:1)
データはNAND上に有っても、ファームウェアが起動しないなら、結果的にSSDとしては機能しなくなります。
ファームウェア更新のみ可能なモードとか、外部からコマンドを受け付けるまで起動すれば希望は有りますが。
万が一管理領域自体が壊れて失われてしまうとNAND上に有るデータは断片化された状態(SSDは、NANDへの書き込み回数の平均化のために連続データも飛び飛びにされる)になり復旧は絶望的になります。
他にも今時はデータをSSD内部で暗号化してから記録している奴が有るのですが、この鍵も管理領域破損時に一緒に飛んだとか、NAND上になくて、開封と同時に鍵が飛ぶ対タンパ仕様だと、完全に積みで「データは結果的に喪失」します。
Re: (スコア:0)
気にしてるのはそこじゃなくて「(おそらくSMART用と思われる)稼働時間カウンタの値が不正なことが、ファームの動作に影響を与えるシチュエーションがいまいち思い浮かばない」なんですが。
一時間単位のような粗いカウンタを参照する必要性があるの？ってとこ。
Re: (スコア:1)
あれ？匿名になっちゃった。
間違ってチェックボックスクリックしたのかな？
うじゃうじゃ
Re:内部的に「時間」を使ってるのか (スコア:1)
ほぼ解決済みのような気がしますが、異常データが入ってきたときにどうするかは設計方針によるかと思います。
大前提として、ストレージに関しては、故障で止まるよりも、壊れたデータが読めた時の方が被害は拡大します。
有り得ない負数が入ってきた＝NANDメモリ等が致命的な障害を起こしたと判定して、
それ以降読んだり・書き込んで状況を悪化させない設計というのも「アリ」だと思いますよ。
管理エリアのデータが壊れた＝書き込めば無事かもしれないデータもどんどん失われるですからね。
Re: (スコア:0)
もっと単純にスレッドセーフでもなんでもないRTOSだから起動しなくなるだけではないの