んなもん担保できるわけがありません。
ファイルの上書きの基本とSQLite
http://d.hatena.ne.jp/syasuda/20091127/1259327062#seemore
3. テンポラリファイルに書き出す。hogehoge.txt
これをもって、ディスク容量の半分以上のサイズのファイルでは適用できないという間抜けな意見を耳にしました。
冒頭に基本のキだと書いてあるのを読めないんですかね。
RDBをファイルシステム上に配置しない理由を考えたことないんですかねこういう人たちは。
そんな大きさのファイルを保存しつつ信頼性を担保したいなら、ファイルシステムなんか使わずに、セクタ単位で追記書き込みをおこなうしか選択肢なんかありゃしませんて。
高信頼性のファイルシステムを使う手ももちろんあります。むしろプログラムの書き方しか知らん人はそれしかないかもしれません。
最近はやりのフラッシュメモリではもう少し考えることが増えます。セクタ単位で書き込んでも、物理デバイス上ではセクタよりも大きなサイズのブロック単位で消去・書き込みがおこなわれるからです。そんな恐ろしいもので、信頼性を担保するには、デバイスレベルでの挙動を深く把握しなければなりません。
EEPROMに格納していた「絶対消えないデータ」や、バッテリバックアップSRAM上の「消えてもらっては困るデータ」しか扱ったことがないようなベテランさんに、フラッシュを使わせると、ろくでもないことが起きるというわけです。
プログラムが書いたとおりに動くはずなんて考えで開発ができるなら、そんな楽な仕事ありませんて。昔の人は、親切なハード屋さんのおかげで楽をしていたに過ぎません。昔の人でも、その辺の事情を把握して「楽をしている」という意識で仕事をしていた人は、今もうまく波に乗っているはずです。それが組み込み力というものでしょう。
SQLiteを提案したのは、高信頼性のファイルシステムをつかっても、間抜けな実装のせいでちっとも効果が出せないことを回避するためです。例えば、高信頼性ファイルアクセス専用関数を使い忘れるとか、スイッチを立て忘れるとかです。
コメント