CannyLSのissue28を再現する

issueそのものについては issue28 を参照してください。

手順

$ cargo build --all

$ rm -f test.lusf

$ ./target/debug/get_unexpected_data --phase=1
put `hoge` to lump_id1(= LumpId("00000000000000000000000000000457")).
delete lump_id1(= LumpId("00000000000000000000000000000457")).
put `foo` to lump_id2(= LumpId("0000000000000000000000000153158e")).

$ ./target/debug/get_unexpected_data --phase=2
try to read a datum from lump_id1(= LumpId("00000000000000000000000000000457")).
We deleted lump_id1(= LumpId("00000000000000000000000000000457")); however, we can read a datum from lump_id1.
Furthermore, the read data `foo` is not `hoge`.

メッセージの説明

1. phase=1では以下のことを行う:
   1. lump_id1に"hoge"をputする。
   2. この段階でjournalをdiskに同期する。
   3. lump_id1をdeleteする。
   4. lump_id2に"foo"をputする。
   5. mem::forgetを呼び出して、プロセスのクラッシュを模倣する。
2. phase=2では以下のことを行う:
   1. lump_id1をgetしようとする。
   2. 削除した筈のlump_id1からデータが読み込める。
   3. 読み込むデータは"hoge"ではなく"foo"である。

原因

• lump_id1をdeleteした段階では、deleteした情報はdiskに永続化されていない。
• 一方で、メモリアロケータは"hoge"の位置にデータを書くことができる。
• 結果的に、lump_id2に対するputで"hoge"のあった位置に"foo"を書き込んでしまう。
• 再起動後には、lump_id1は生存しているように見えてしまい、結果として"foo"を読み出す。