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秒
まったく同じになるとは予想していなかった。