1

私はARM9で実行されている組み込みLinuxに取り組んでいます。ファイルシステムは ext4 タイプ (rw、sync、noatime、data=writeback) です。unsync を有効にして、Write-Ahead-Loggin (WAL) モードで SQLite3 データベースに書き込み/読み取りを行うプロセスを実装しました。電力損失が発生した場合、DB の同期とチェックポイントによってすべてのデータを保存するのに約 2 秒かかります。しかし、それでも、私の場合は本当に良くないDBが壊れていることがあります。

私の目的のために新しい DB エンジンを書きたいと思います。DB が 1 つのファイルに保持される SQLite と同様の方法で。ただ、この場合、ヘッダーデータを1セクターに書き込み、残りのデータを少なくとも2セクター後に書き込むことを考えているため、DBのサイズは大きくなりますが、データを書き込むときに、ヘッダーを台無しにすることはありませんインデックスなどを保持するファイルの。そうすれば、SQLiteの動作と同様に、すべてのファイルではなく、最後のデータのみが破損します。

私の質問は、私のアプローチが正しいかどうかです。

4

1 に答える 1

0

あなたはピンポンテクニックを使うことができます。

ピンポンテクニックでは、2 つの別々のファイルを使用し、交互に書き込みます。最悪の場合に停電が発生した場合、破損したファイルは 1 つだけで、もう 1 つのファイルは安全に使用できます。最良の場合、それらのいずれも破損していないため、最新のものを引き続き使用できます.

ハッシュ関数またはその他の CRC スキームを使用すると、破損したファイルを簡単に検出できます

明らかに、このスキームは、フードの下で動作している可能性のある書き込みキャッシュまたはその他のディスク キャッシュ メカニズムからあなたを救いません。

または、独自のデータ整合性保護機能を備えたジャーナル ファイル システムを使用することもできます。

ピンポンおよびジャーナリング スキームは、データの整合性のみを保証することに注意してください。データの損失は依然として発生する可能性があります。データの完全性とデータ損失は、まったく別のものです

于 2014-09-17T10:10:09.700 に答える