アカウント名:
パスワード:
アプリフォルダへのデータファイル(大抵は設定ファイル？)の書き込みがデフォでは禁止されてたりするんだったよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
書き換え可能回数 (スコア:1, 興味深い)
まだ先の話？
Re:書き換え可能回数 (スコア:1, 興味深い)
毎日最低1回はハイバネートする使い方で、まだなんともない。スワップファイルやら
ブラウザのキャッシュやらも、特に気にせずゴリゴリ書いてるのに。
SSDよりむしろバッテリ寿命の方がヤバイ。かなりヘタって来てる。
Re:書き換え可能回数 (スコア:2, 参考になる)
当時「Flashメモリをswapに使ったりしたらあっという間に寿命が来る」などと忌避する意見も出てましたが、
「外付けSDなら寿命が来てもすぐ交換できるし、たぶん本体が陳腐化する方が早い」と考えて実施。
その予測通り、SL-C700が退役するまで、結局Flashはトラブルすることはありませんでした。今はW-ZERO3を使用中。
Re: (スコア:0)
アプリフォルダへのデータファイル(大抵は設定ファイル？)の書き込みが
デフォでは禁止されてたりするんだったよね。
それってつまり、
OS本体(?)が置いてあるディスクの「ROM化」をしやすい、ってことだよね。
これは実際にROMに焼くという意味とは限らず、FLASHだけど書き込みは(OS/アプリ/ライブラリ/ドライバの)Install時しかおこなってないねえ…という運用も、一種のROM化だと考えられる。Flash書き込みに対するリスクを回避できているのだから。
FLASH系マシンを(Vista入りで)仕立てる各社も、そのへん考慮してるのかな？
Re:書き換え可能回数 (スコア:2, 参考になる)
ユーザーアプリが書き込めないといっても、システム自身がいろいろ書き込みを行ってますので(例えば、「レジストリ」情報を保存したファイルとか)
「一種のROM化」とまでは言えないかと。
そのあたりの保存場所をシステムドライブから分離するのはなかなか難しいと思います。
Knoppix がやってるような方向(システムそのものはreadonly(CD-ROM/DVD-ROM 上のファイルシステムに、UnionFSを使って見かけ上は書き込み可能にする)
が現実的でしょうか。
普段のファイル更新は外付けで容易に交換可能なメモリに対して行い、時々本体内蔵ドライブを更新するとか。
Windows用のシステムドライブにも使える「union FSみたいなもの」ってのは聞いたこと無いのですが、
VMwareとかを使えば、システムはreadonlyな環境を実現できそう。
#昔、UNIX MAGAZINE で読んだんですが、どこかの学校の学生用PCは
#Linux上のVMwareでWindowsを動かすことで、完全readonlyな(いきなりブチっと電源切っても問題ない)システムになってたとか。
Re: (スコア:0)
>VMwareとかを使えば、システムはreadonlyな環境を実現できそう。
つ Enhanced Write Filter
http://monoist.atmarkit.co.jp/fembedded/winembedded/xp01/xp01.html
Re: (スコア:0)
いえ。
どちらかと言えばセキュリティ関連ですよ。
最低でもWin2k時点でアプリケーションフォルダに書き込むのは良くない挙動として既に非推奨でした。
Win2kのユーザー(Users)/XPの制限ユーザーだとProgram Files以下は書き込めません。
Win9xの互換性とか設定ファイルを探すの面倒といったユーザーへの利便性重視で同一フォルダに作ってましたが。
その無視してきたツケがVista対応で出てる感じですね。
ツギハギしてたらパス取得方法がルーティンによって違うせいで上手く動かないとか含めて。
お前はもう死んでいる。ただし3%だけ。 (スコア:1, 興味深い)
たしか現実に売られてるFLASHディスクは、
(内部のコントローラが)
ディスク全体を細かく(数kbごととか？に)分けて管理してて、
その管理単位で生死をチェックする、
のではなかったでしょうか？
つまり死んでたらそのブロックを放棄する、という運用が自動化されてる。
そしてFLASHに「書き込めば」いつか壊れる、
ということは裏返せば、
「(その理由で)破損が発生するのは書き込み時に限る」
と言える…のでしょうかもしかして？
だとすればですが、
今書いてるブロックが破損したら、
破損ブロックを放棄するいっぽうで、
そのブロックに書くつもりだった分を「別のブロックに」書き直す
(そのときOSにも支援を仰げるでしょうか？「xxxバイトを再送してください」とか。ようするに「さっきのxxxバイトの書き込み要求はFAILしました」とエラーを返せばいいかな)
ということをし続けることで、
DiskFullを食らう日が来るまでは
破損の実害は見えない、
ということになるのかなと思いました。
(あと急ぐときに書き込みが間に合わないというリスクも有るはず。
なかなか搬送先が見つからない哀れな救急車状態。
これはブロックごとの書き込み回数を記録しとけばベストだろけど、
いつ破損するかはどうせ確率的にしか判らないし、
そのくせ記録すべき量ばかり多いからコストバランスが悪いんで、
そんなもの管理するよりは、
書き込みブロックの選択をランダムにバラケさせるほうが話が早い。
たしか実際に書き込み位置はバラケさせるよう内部で制御されるのでしたよね。
)
そして、そうだとすれば、ディスクの傷み具合(割合)は、たんにdfで今のディスクサイズが元と比べて何割減ってるか？を見れば判る、という利便性の高い話になる。(コントローラがそれを報告し、OSがその報告を動的に処理してくれるならば、ですが)
それで、実際のFLASH製品もこうなってるのでしょうか？＞詳しいかた
Re: (スコア:0)
各社非常に固い企業秘密なので。
まあちゃんと考えられてるんじゃないですか、角度とか。
Re: (スコア:0)
って気はしますがどうなんでしょう？
Re: (スコア:0)
>>
あるいはそれが都市伝説であったことが証明される・・・わけないか。
Re: (スコア:0)