On 3/10/16, 6:06 PM, "ceph-devel-owner@xxxxxxxxxxxxxxx on behalf of Allen Samuels" <ceph-devel-owner@xxxxxxxxxxxxxxx on behalf of Allen.Samuels@xxxxxxxxxxx> wrote:
<snip>
>
>Thus the total allocator system becomes:
>
>(1) An in-memory bitmap vector of 4K blocks (this is the equivalent of the FreeList of the current design).
>(2) The auxiliary structures described above (~1MB of memory extra).
>(3) Allocations set bits in the bitmap at the time of allocation.
>(4) Deallocating operations are done after the KV commit.
>(5) KV keys become chunks of the bitmap and are manipulated at the individual bit level via the merge capability of RocksDB (which we would duplicate in ZetaScale).
I take it you mean the KV *values* become chunks of the freelist bitmap? While the key is... the index to the chunk of bitmap the value is? Since the merge operation is modifying the value for a given key.
How are you deciding the size of bitmap chunks to use?
-Emile Snyder
��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
