# Amphishea: A Novel Persistent Buffer Management Strategy to Improve SMR Disk Performance
## 5 Amphisbaena Design
### Locality-Aware Buffer Space Management
#### 5.2.2 Space Allocation for the Persistent Buffer  
The space allocator allocates space to blocks labeled as cold and hot blocks based on the processing results of the data classifier. For those blocks that are routed to the LFB, since each block is statically mapped to only one specific chunk, chunk-level mapping is used to maintain the mapping information of the LFB. The space allocator first locates the address of the chunk's mapping entry based on the chunk location tree (CLT) in Figure 10a. The key of each tree node is the sum of chunk_num and zone_chunk, and the value is the address of the mapped entry. The chunk_num can be calculated by Equation (2), where  
Figure 8: The internal data layout space of the persistent buffer. Figure 9: An illustration of the relationship between chunk and SMR. \(CHUNK\_BLOCK\) and \(ZONE\_BLOCK\) denote the number of blocks contained in a chunk and zone, respectively. \[chunk\_num=\lfloor\frac{block\_num-zone\_num\times ZONE\_BLOCK}{CHUNK\_ BLOCK}\rfloor \tag{2}\]  
Subsequently, the space allocator updates the metadata of the specified mapping entry in the chunk mapping table (CMT) based on the returned address. As shown in Figure 10b, the CMT contains five fields, namely id, zone_num, chunk_offset, max_block_offset, and min_block_offset. Finally, blocks with cold labels are written to the appropriate chunk. Note that blocks with cold labels that already exist in the HFB are updated in their original location instead of being redirected to the chunk. Compared to the blocks labeled as cold, the blocks labeled as hot routed to the HFB are more complicated to handle because any hit on a role block can result in a role conversion. To speed up locating the buffer blocks in the HFB, a hash-based block-level mapping as shown in Figure 10c is created, where LBA and physical block address (PBA) denote the key and value, respectively. After retrieving the metadata of a hit block, the data classifier updates the roles of the blocks in the HFB according to the changes in the update period. The following describes the detailed manipulation of a block to be updated. * **Shadow block write hit. ** As mentioned in Section 5.1.1, the shadow block refers to those block numbers that are labeled as cold and are not in the HFB. In fact, the data classifier must record these block numbers to correct the misclassification caused by insufficient prediction accuracy in the first phase. Otherwise, the truly hot blocks that were misclassified as cold will never have a chance to be found. When a shadow block entry is hit, it changes from a non-resident block to a resident block, and its role is changed to LUP, then the new LUP block is moved to the MRU end of the filter list, and the resident list. * **Ghost block write hit. ** Although ghost blocks and shadow blocks are both non-resident blocks that record historical information, there are subtle differences between them. Unlike the latter, the ghost block records the block numbers of those that have been removed from the filter list. The write hit of these blocks indicates that they have long update periods and high update frequency. Consequently, after a ghost block is updated, its role is immediately changed to SUP and moved to the MRU end of the resident list. * **LUP block write hit. ** Blocks loaded into HFB for the first time remain in the filter list before being hit again. When an LUP block is hit, its operation includes two cases. First, if the hit LUP block exists in both the filter list and the resident list, the hit block is removed from the filter list and inserted as an sup block at the MRU end of the resident list. Then, the SUP block at the bottom of the resident list is converted to an LUP block and moved to the LRU end of the filter list, which is called a prune operation. Meanwhile, other block entries between the old bottom SUP block and the new bottom SUP block are also removed.