VEA optimization

Version Extent Allocator (VEA) of DAOS uses B+Tree to manage space for DT-blob, it can only allocate 4K aligned extent. Free space of VEA can be split into many fragments by allocated extents after running over the time, each fragment is indexed by a B+Tree leaf node.

For example, 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 for object; in addition, new write may overlap and land into middle of existent extent, which generates 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 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 a B+Tree leaf node.