sghemawat

5 ms·

1.
by sghemawat 8mo ago
Hi Kenton! No worries at all. I tend to be quieter than Jeff anyway (less public speaking etc.) and I am happy to not have a dedicated website. :-). -Sanjay
2.
by sghemawat 14y ago
Not your fault. We just plain forgot to update the documentation, so the freshest available document is a few years out of date.
3.
by sghemawat 14y ago
About [1] Sorry about that: the document you linked to is amazingly stale. tcmalloc has been releasing memory to the system for many years. See for example the IncrementalScavenge routine in a version of page_heap.cc from Dec 2008: https:
4.
by sghemawat 15y ago
We have no such plans. The library is designed so that concurrency control is outside its scope. If I needed it for an application, I might consider using some application level code that looks like: bool CAS(db, key, oldvalue, newv
5.
by sghemawat 15y ago
The use of c++0x should be limited to the small AtomicPointer class in port_posix.h. The class uses <cstdatomic> for its implementation. If you can provide a different implementation of "acquire store" and "release load" for your
6.
by sghemawat 15y ago
Merely an incomplete one. Leveldb never writes in place: it always appends to a log file, or merges existing files together to produce new ones. So an OS crash will cause a partially written log record (or a few partially written log recor
7.
by sghemawat 15y ago
leveldb is a persistent ordered map; bitcask is a persistent hash table (no ordered iteration). bitcask stores a fixed size record in memory for every key. So for databases with large number of keys, it may use too much memory for some app
8.
by sghemawat 15y ago
One of the leveldb authors here. TokyoCabinet is something we seriously considered using instead of writing leveldb. TokyoCabinet has great performance usually. I haven't done a careful head-to-head comparison, but it wouldn't surprise m
9.
by sghemawat 15y ago
It is durable from an OS perspective. I started typing in a long explanation, but I think the comment for the "sync" field in the options.h file captures things well: struct WriteOptions { // If true, the write will be flushed from