Even if you only ever have 40 megs worth of live entries in a database, you can
get into situations where the disk space used continues to grow and grow
without bound.
What steps will reproduce the problem?
1. Run the test in the following patch
https://github.com/chirino/leveldb/commit/028fdd112e3a3895f6fcd89a7cd6d252495c41
89.patch
What is the expected output? What do you see instead?
The test results in the following:
0% done. Using: 0.00 MB
Deletes starting. 2% done. Using: 35.17 MB
10% done. Using: 143.51 MB
20% done. Using: 147.94 MB
30% done. Using: 147.94 MB
40% done. Using: 147.94 MB
50% done. Using: 149.68 MB
60% done. Using: 298.99 MB
70% done. Using: 414.35 MB
80% done. Using: 542.32 MB
90% done. Using: 651.77 MB
Deleting remaining live records...
Counting records...
Database contained 0 entries.
Using: 741.56 MB
Value 777581808 is not in range [0, 8388608]
db/db_test.cc:1075: Assertion failure Between(Size("", Key(totalKeys)), 0,
1024*1024*8)
What I would expect to happen is that there should be some upper limit to how
much space the database uses no mater how many insert/deletes occur if there is
a fixed size size of 'live' records. So perhaps output like:
0% done. Using: 0.00 MB
Deletes starting. 2% done. Using: 35.17 MB
10% done. Using: 143.51 MB
20% done. Using: 147.94 MB
30% done. Using: 147.94 MB
40% done. Using: 147.94 MB
50% done. Using: 149.68 MB
60% done. Using: 147.94 MB
70% done. Using: 147.94 MB
80% done. Using: 147.94 MB
90% done. Using: 147.94 MB
Deleting remaining live records...
Counting records...
Database contained 0 entries.
Using: 147.94 MB
What version of the product are you using? On what operating system?
Git master commit 514c943a8e9ce1b06c55ae5e47008f6b0854b36c on OS X
Please provide any additional information below.
This may be related to issue 77 and was discussed on the mailing list at
https://groups.google.com/d/msg/leveldb/yL6h1mAOc20/vLU64RylIdMJ
Original issue reported on code.google.com by chir...@gmail.com on 18 Apr 2013 at 5:29
Original issue reported on code.google.com by
chir...@gmail.comon 18 Apr 2013 at 5:29