アカウント名:
パスワード:
こういったのって、内部では秒をつかって表示・出力するときに時間とかに換算する場合が多いと思ってたけど、内部でも時間をつかってたのか
これ、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メモリ等が致命的な障害を起こしたと判定して、それ以降読んだり・書き込んで状況を悪化させない設計というのも「アリ」だと思いますよ。管理エリアのデータが壊れた＝書き込めば無事かもしれないデータもどんどん失われるですからね。
ウェアレベリングとかは？フラッシュのデータ揮発防止用にあるブロックがどれくらいの時間移動していないかを管理するのに使っていたら、オーバーフローすることでウェアレベリングに異常をきたし、ライトするブロックの平均化がうまく行かなくなってフラッシュが短時間でぶっこわれてしまうとかはないかな？
疑問点は「なぜ稼働時間を計算しているのか分からない」(解決済み)と「なぜサブルーチンの一つが異常終了しただけで装置の異常動作が引き起こされるような設計が許容されるのか分からない」の2点かな?
なるほど、書き込み頻度が高いとこを見つけるのは回数だけ見れば十分だろうけど、頻度の低いとこを探すには経過時間を基準にした方がいいだろうし、精度が粗くても支障はない。だけど元にするカウンタがオーバーフローする可能性は見落としていたと。本当にそれが理由かはわからないけど、なんかありそうですね。
(すばらしい洞察)
もっと単純にスレッドセーフでもなんでもないRTOSだから起動しなくなるだけではないの
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
内部的に「時間」を使ってるのか (スコア: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)
ウェアレベリングとかは？
フラッシュのデータ揮発防止用にあるブロックがどれくらいの時間移動していないかを管理するのに使っていたら、オーバーフローすることでウェアレベリングに異常をきたし、ライトするブロックの平均化がうまく行かなくなってフラッシュが短時間でぶっこわれてしまうとかはないかな？
Re: (スコア:0)
疑問点は「なぜ稼働時間を計算しているのか分からない」(解決済み)と「なぜサブルーチンの
一つが異常終了しただけで装置の異常動作が引き起こされるような設計が許容されるのか分からない」
の2点かな?
Re:内部的に「時間」を使ってるのか (スコア:1)
なるほど、書き込み頻度が高いとこを見つけるのは回数だけ見れば十分だろうけど、頻度の低いとこを探すには経過時間を基準にした方がいいだろうし、精度が粗くても支障はない。
だけど元にするカウンタがオーバーフローする可能性は見落としていたと。
本当にそれが理由かはわからないけど、なんかありそうですね。
(すばらしい洞察)
うじゃうじゃ
Re: (スコア:0)
もっと単純にスレッドセーフでもなんでもないRTOSだから起動しなくなるだけではないの