アカウント名:
パスワード:
こういったのって、内部では秒をつかって表示・出力するときに時間とかに換算する場合が多いと思ってたけど、内部でも時間をつかってたのか
これ、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用と思われる)稼働時間カウンタの値が不正なことが、ファームの動作に影響を与えるシチュエーションがいまいち思い浮かばない」なんですが。一時間単位のような粗いカウンタを参照する必要性があるの？ってとこ。
単純にintカウントのオーバーフロー対応をしていなくて、カウントがオーバーフローした結果、隣のメモリ領域にまであふれ出して上書きー＞上書きしたところがクリティカルな部分でコンロローラ全体アボン
みたいなあほな理由な気がする。
一瞬だけそれは考えたけど、最上位ビットによって書き込みサイズが変化するなんてのはわざわざそうする必要があるとき(UTFのような可変長エンコードとか)にするめんどくさい実装であって、そんなのをうっかり仕込んでしまったと考えるのはかなり無理があるので自分の中では却下した。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
内部的に「時間」を使ってるのか (スコア: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: (スコア:0)
単純にintカウントのオーバーフロー対応をしていなくて、
カウントがオーバーフローした結果、隣のメモリ領域にまであふれ出して上書きー＞上書きしたところがクリティカルな部分でコンロローラ全体アボン
みたいなあほな理由な気がする。
Re:内部的に「時間」を使ってるのか (スコア:1)
一瞬だけそれは考えたけど、最上位ビットによって書き込みサイズが変化するなんてのはわざわざそうする必要があるとき(UTFのような可変長エンコードとか)にするめんどくさい実装であって、そんなのをうっかり仕込んでしまったと考えるのはかなり無理があるので自分の中では却下した。
うじゃうじゃ