# Amphishea: A Novel Persistent Buffer Management Strategy to Improve SMR Disk Performance
## 5 Amphisbaena Design
### Latency-Sensitive Garbage Collection  
To mitigate the impact of buffer cleanup on user requests, the garbage collector uses a latency-sensitive garbage collection policy to schedule cleanup activities in the LFB and HFB. This policy reduces the cost of buffer cleanup in three ways: using different cleanup patterns for the LFB and HFB, splitting the garbage collection process, and detecting write requests to victims. **The LFB cleanup. ** As the entry for blocks into the persistent buffer and the only exit for blocks to the native zone, the LFB experiences most of the write traffic. Therefore, the cleanup efficiency of the LFB has a direct impact on user request latency. Although the garbage collector can use the inter-request interval to actively schedule LFB cleanup to reduce the time of blocked user requests, in I/O-intensive workloads, there is not enough free interval to complete a large-scale zone-level garbage collection. To balance user request latency and write amplification, the garbage collector splits the victim zone collection process into multiple stages at chunk granularity. When collecting victim blocks, if the garbage collector detects write requests for the current victim in the I/O request queue, it stops collecting at the next completion checkpoint and writes the victim back to the native zone as soon as possible. Note that we do not use a log to redirect incoming data, not only to reduce the subsequent data synchronization overhead but more importantly, because incoming write requests may update the victim, which means that the write-back data is invalid. In addition, the garbage collector takes their spatial locality into account when selecting victims. This is because the victim blocks merge with the old cluster to form a new cluster, and the strength of their spatial locality determines the current fragmentation level of the native zone. If the distribution of blocks in the new cluster is fragmented, it increases the probability of triggering RMW when future victims are written back. In practice, a fragmented block layout also increases the time it takes to collect blocks in the native zone during RMW. Therefore, a new metric called fragmentation level (FL) is introduced to quantify the spatial locality of a victim. The fragmentation level of a victim is calculated by Equation (3), where native_block and write pointer (wp) denote a block and the block pointed to by the write pointer in the native zone, respectively, and victim block (vb) denotes a block in the LFB. Finally, the weight of the victim is calculated according to Equation (4), where chunk_cnt is the number of chunks contained in the victim. \[FL\!\!=\!\!\left\{ \begin{array}{ll}\frac{\sum_{i=wp}^{N}{\mathit{ victim\_block}}_{i}}{Block\_Offset({\mathit{ victim\_block}}_{n}-wp)}&vb\geq wp\\ \frac{\sum_{i=1}^{N}{\mathit{native\_block}}_{i}+\sum_{j=1}^{M}{\mathit{ victim\_block}}_{j}}{Block\_Offset(wp)}&vb<wp\end{array} \right. \tag{3}\]  
\[{\mathit{Victim\_Weight}}={\mathit{chunk\_cnt}}*FL_{\mathit{ victim_{i}}} \tag{4}\]  
**The HFB cleanup. ** Most of the resident blocks in the HFB are frequently updated blocks, so the garbage collector must delay the HFB clean up as much as possible to prevent the hot blocks from moving back and forth between the persistent buffer and the native zones. Consequently, the garbage collector will only passively schedule the HFB cleanup process when the resource in the HFB is exhausted. As described in Section 5.1, the filter list is the only exit for blocks leaving the HFB. When the HFB buffer cleanup process is triggered, the garbage collector searches for victims from the LRU end of the filter list. The number of evicted victims in the HFB is related to the presence of a mapped chunk in the LFB. That is, if the corresponding chunk already exists in the LFB, the garbage collector evicts only one block at a time; conversely, blocks belonging to the same chunk in the filter list are evicted in bulk to make full use of the chunk's storage space.