RFC: DB_PRIVATE フラグの削除
ウォレットのバックアップやその他の DB 検査は、安全でアトミックかつトランザクショナルな方法で容易に実行可能である……ただし、DB_PRIVATE フラグが削除された場合に限る。
DB_PRIVATE を削除すると何が起きるか、もっと詳しく教えてもらえるか？
DB_PRIVATE に特定の理由があったか、それともサンプルコードからフラグをコピーしただけか覚えていない。DB_PRIVATE を削除すると、他のプロセスが同時にデータベースを開いても安全になるか？副作用次第では改善かもしれない。すべての変更を即座に書き出す必要があったり、他の調整が必要になったりして、性能が大幅に低下するか？追加のロックや調整ファイルが必要になるか？他に何が変わるか？DB_PRIVATE の有無で初期ブロックダウンロードの時間を計ってテストできる。ネットワークが要因にならないよう、できればローカルマシンに -connect するとよいだろう。
どうやら、DB_PRIVATE は期待するような動作をしないようだ。つまり、他のプロセスがデータベースを開くことを防ぐのではなく、開くことは許可するものの、開くと問題が起きるだけだ。もう一つの選択肢は、方法があれば、データベースファイルをロックして他のプロセスからアクセスできないようにすることだ。
DB_PRIVATE は、データベースにアクセスするプロセスが 1 つだけであると仮定することで、いくつかの最適化を有効にする。特にこのフラグにより、db4 は OS が提供する重い flock や共有メモリーの代わりに pthread スタイルの mutex ロックを使用できる。参考：DB_ENV->open のドキュメント。
一般的な動機は、(a)DB_PRIVATE を削除し、(b)Bitcoin が db4 トランザクションを適切に使用すれば、db4 データベースを Bitcoin クライアントと並行して安全にアクセスできるということだ。コードが適切にアーキテクチャされていれば、db4 トランザクションは blk0001.dat のような非 db4 データを含むラップにも使用できるかもしれない。
rev 153 で DB_PRIVATE フラグなしで試している。何が異なるか注視する必要がある。
少なくとも Windows では、24KB から 4MB のサイズの__db.001 から__db.006 の 6 つのファイルを作成する。終了時にそれらを削除せず、そのまま残す。
ドキュメントによると、メモリーマップドファイルを使用するとのことだ。データベースファイルと同じファイル権限を持ち、同じユーザーアクセス制限が適用されると思われる。
Windows プライベート LAN での 78500 ブロックのダウンロードテスト： DB_PRIVATE あり 20分51秒 DB_PRIVATE なし 20分51秒
まったく同じになるとは予想していなかった。