ssh-agentの次はgpg-agentか... こういうのって、統合できないもんなんですかね？ KDEのKWalletとか、Mozillaに組み込みの記憶機能とか、 自分から見れば同じ目的としか思えないものがこうもたくさんあると、 うっとうしく感じませんか？
結論としては、NDBの耐故障性はまだ機能していないってことか。 私としてはパフォーマンスの方が気になるので、 誰か試して欲しいのぉ。 こればかりはある程度ハードウェアが整わないと実験できないので、 自分は人柱になれそうにもありませぬ。
とりあえず、とある顧客のある時点でのData.fsを使って、 いくらか調べてみました。 ファイルの大きさは1942154571バイト。 これはpackしてしまっているので、すごく小さくなってますが、 しばらく放って置くと、40GB超える事がよくあります。
得られたデータはこんな感じ。
packしてしまっているので、abortされたトランザクションは全く無し、 同一oidのオブジェクトはごく僅かしか含まれていません。 この状況では明らかに差分を使う意味はありません。
次にgzipかけたらどうなるかを見てみました。 gzipはデータ部分のみで、 ヘッダやバージョン等は含まないことにしました。
案外データ長が短くても、gzipは圧縮率は良いことが分かります。 ちなみに、デフォルトのレベル6で圧縮してます。
これで分かるのは、圧縮なしだと、一つのトランザクションが（平均で） 4KBを越えるのに対し、圧縮ありだと、 ヘッダを含めても越えなくなるということ。 ファイルシステムが2KBや4KB単位のブロックを利用することが多いのを考慮すると、 一つのトランザクション内のオブジェクトが少ないブロック数に収まる可能性が高くなるので、 多少はパフォーマンスが上がるかもしれません。 同じトランザクションに存在するオブジェクトは関連性が高いと考えられるので、 意味があるかもしれないという訳です。
しかし、こればかりは実際にベンチマークしないとよく分かりません。 実装するのは面倒そうだなあ。 FileStorageを改造するのは簡単だと思いますが、 既存のData.fsを変換するのは大変そうです。 オブジェクトの位置関係を保持したままテストしたいのですが、 圧縮するとバイト位置が変化してしまいますからね。