Write handling of WORM object

All data are stored as regular(hierarchical) objects initially, because it is very challenging to handle write in flattened format (MVCC, ilog, DTX…). In addition, even for WORM object, application can still submit writes in multiple RPCs, e.g., appends, in this case, it is complex to add new keys and values to flattened buffer. To avoid these complexities, this design does not change the write handler, which creates trees to index keys and values for write request.

Flattening service

DAOS can provide API to allow user to indicate immutability of WORM objects:

...

Because DAOS only flattens small objects, so it should be able to store multiple flattened objects in the same SSD extent to avoid fragmentation and reduce write amplification.

WORM object eviction

After flattening service serialized WORM objects and wrote them to DT-blob, these objects can be evicted from DRAM. DAOS stores the BIO address of evicted object in the object index tree, which always stay in DRAM. When read request against evicted object arrived at server, if VOS found the object has already been evicted from DRAM, it can read the entire object back by one BIO call.

Read handling of flattened WORM object

DAOS will have a new read handler for flattened object, it can locate the requested key and value from the flattened object format by leaner search. Because flattened object is stored in DT-blob and it can be evicted from DRAM, if storage engine receives a read request against an evicted object, it can bring the entire object back to DRAM by one SSD read.

...