Feature Request: more control over, better information about disk space utilization

[GoogleCodeExporter]

In an embedded system or a handheld computer like an iPhone, space is at a 
premium. It's often important to maintain strict control over database size 
growth.

Please enhance leveldb to provide better runtime control over the amount of 
disk space used and/or provide more complete, up-to-date information about how 
much space is bing used, so that it's possible to remove entries to make more 
space. The current size estimate functionality is often dramatically wrong, 
even after closing and re-opening the database (I see values off by 75% or more 
versus file system measurements).

Also, please provide a reliable compaction interface for mere mortals who don't 
know how the Internals work. The current DB::Compact() method has the opposite 
to the intended effect: the database grows dramatically each time it's invoked. 
The only way to get actual compaction behaviour seems to be to close and 
re-open the database.

Original issue reported on code.google.com by bgulanow...@gmail.com on 3 Nov 2011 at 8:46

[GoogleCodeExporter]

After uncovering a bug in my own code where an Iterator was being leaked, I'm 
seeing improvements in the behaviour of the memory size reporting, as well as 
more reliable automatic compaction in the background. It apparently relates to 
Versions being kept alive by the Iterators.

Some additional discussion in the documentation, to the effect that live 
Iterators may impact various database functions (including deletion) would be 
desirable. Alternately, could each Version be owned by the Iterator responsible 
for its creation, instead of all Versions being owned by the database? Or since 
the database maintains ownership of Versions, should it not maintain ownership 
of Iterators, too?

Original comment by bgulanow...@gmail.com on 4 Nov 2011 at 3:47