Version Extent Allocator (VEA) of DAOS uses B+Tree to manage blob space, it can only allocate 4K aligned extent. It means that the free space will be split into many fragments by allocated extents after running over the time, each fragment is indexed by a B+Tree leaf node. If DAOS is deployed as backend of block storage, the main workload consists of 4K, 8K,… 64K reads and writes, which may include significant amount of overwrites. For each of these small writes, DAOS calls VEA to allocate the blob extent and also create EVTree leaf node to address data; in addition, new write may land to middle of existent extent and generate a new piece of free fragment in VEA after aggregation. In the worst case, date extents and free fragments interleave with each other, DAOS either has EV-Tree or B+tree leaf node (metadata) for each of them.
Because EV-Tree is tightly coupled with multi-version data model of DAOS, it is difficult to make it more compact. On the other hand, creating B+Tree leaf node for each free fragment is not always the most efficient way if the workload includes massive blocked aligned overwrites. To reduce metadata overhead, VEA can use bitmap to manage free space for small allocation. In this case, each free fragment can be represented by a few bits or bytes, instead of B+Tree leaf node.