アカウント名:
パスワード:
予算のせいじゃない。メモリの物理的特性を知らないプログラマが書き換え上限を超えるようなプログラムを書いたせい。知る中で最も旧い例は、『ナナオ、液晶ディスプレイに不具合、1月下旬より修理 ~電源ボタンを押しても画面が表示されない場合も [impress.co.jp]』(2002年)保存した設定情報を定期的に現在値で上書きする、なんてのは珍しくないけど、DRAMと同じ感覚をストレージに対して持ち込むと、やっちまったな! 事案になる。このへんはファームを書く人ではもう常識だと思ってたけど、まだやらかす人はいるんだな。
通常eMMCはコントローラ内蔵で、コントローラ側で自動でウェアレベリングするのではないの?だから、特定ブロックに書き込みが集中することは無い
効果は空き容量次第ログが容量を圧迫していたら効果はない。新しい書き込みのために既存のデータを再配置していたらストレージがまんべんなく消耗するだけ。
書き換え回数上限の話なのに容量圧迫が原因って誤解されてるのは海外の話でしょ
...みたいなウェアレベリングが昔は多かったけど、最近は空き容量で顕著に差が出るほどのやつはあまりない。むしろ細かくTRIM(というよりDISCARD)出すほど逆に劣化しやすくなる。書き換え回数だけでなくread/write性能も見た上での妥協点に落ち着いたのかなという気がする。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
宛:部門名 (スコア:4, 参考になる)
予算のせいじゃない。メモリの物理的特性を知らないプログラマが書き換え上限を超えるようなプログラムを書いたせい。
知る中で最も旧い例は、『ナナオ、液晶ディスプレイに不具合、1月下旬より修理 ~電源ボタンを押しても画面が表示されない場合も [impress.co.jp]』(2002年)
保存した設定情報を定期的に現在値で上書きする、なんてのは珍しくないけど、DRAMと同じ感覚をストレージに対して持ち込むと、やっちまったな! 事案になる。
このへんはファームを書く人ではもう常識だと思ってたけど、まだやらかす人はいるんだな。
Re: (スコア:0)
通常eMMCはコントローラ内蔵で、コントローラ側で自動でウェアレベリングするのではないの?
だから、特定ブロックに書き込みが集中することは無い
Re: (スコア:0)
効果は空き容量次第
ログが容量を圧迫していたら効果はない。
新しい書き込みのために既存のデータを再配置していたらストレージがまんべんなく消耗するだけ。
Re:宛:部門名 (スコア:0)
書き換え回数上限の話なのに容量圧迫が原因って誤解されてるのは海外の話でしょ
Re:宛:部門名 (スコア:1)
Re: (スコア:0)
...みたいなウェアレベリングが昔は多かったけど、
最近は空き容量で顕著に差が出るほどのやつはあまりない。
むしろ細かくTRIM(というよりDISCARD)出すほど逆に劣化しやすくなる。
書き換え回数だけでなくread/write性能も見た上での妥協点に落ち着いたのかなという気がする。