アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
書き換え可能回数 (スコア:1, 興味深い)
まだ先の話？
お前はもう死んでいる。ただし3%だけ。 (スコア:1, 興味深い)
たしか現実に売られてるFLASHディスクは、
(内部のコントローラが)
ディスク全体を細かく(数kbごととか？に)分けて管理してて、
その管理単位で生死をチェックする、
のではなかったでしょうか？
つまり死んでたらそのブロックを放棄する、という運用が自動化されてる。
そしてFLASHに「書き込めば」いつか壊れる、
ということは裏返せば、
「(その理由で)破損が発生するのは書き込み時に限る」
と言える…のでしょうかもしかして？
だとすればですが、
今書いてるブロックが破損したら、
破損ブロックを放棄するいっぽうで、
そのブロックに書くつもりだった分を「別のブロックに」書き直す
(そのときOSにも支援を仰げるでしょうか？「xxxバイトを再送してください」とか。ようするに「さっきのxxxバイトの書き込み要求はFAILしました」とエラーを返せばいいかな)
ということをし続けることで、
DiskFullを食らう日が来るまでは
破損の実害は見えない、
ということになるのかなと思いました。
(あと急ぐときに書き込みが間に合わないというリスクも有るはず。
なかなか搬送先が見つからない哀れな救急車状態。
これはブロックごとの書き込み回数を記録しとけばベストだろけど、
いつ破損するかはどうせ確率的にしか判らないし、
そのくせ記録すべき量ばかり多いからコストバランスが悪いんで、
そんなもの管理するよりは、
書き込みブロックの選択をランダムにバラケさせるほうが話が早い。
たしか実際に書き込み位置はバラケさせるよう内部で制御されるのでしたよね。
)
そして、そうだとすれば、ディスクの傷み具合(割合)は、たんにdfで今のディスクサイズが元と比べて何割減ってるか？を見れば判る、という利便性の高い話になる。(コントローラがそれを報告し、OSがその報告を動的に処理してくれるならば、ですが)
それで、実際のFLASH製品もこうなってるのでしょうか？＞詳しいかた
Re: (スコア:0)
各社非常に固い企業秘密なので。
まあちゃんと考えられてるんじゃないですか、角度とか。
Re: (スコア:0)
って気はしますがどうなんでしょう？