# Amphishea: A Novel Persistent Buffer Management Strategy to Improve SMR Disk Performance
## 2 Background and Motivation
### Motivation
Worse, victims can only be evicted in a FIFO fashion, regardless of update frequency, so some frequently updated blocks will migrate back and forth between the persistent buffer and the SMR zone. Compared to the former, the segment-based persistent buffer data layout scheme reduces the time-consuming collection of victim blocks to some extent by storing the blocks in fixed-size segments. However, to improve space utilization, a segment can often be shared by more than one SMR zone. Therefore, this scheme triggers a large number of RMW operations when evicting victims, resulting in unpredictable write-back overhead. In addition, most workload write requests do not always access the LBA space uniformly, and this inflexible mapping method results in wasted buffer space. To illustrate this phenomenon, we analyzed some real workloads of MSR. As shown in Figure 2(a), the write requests cover the entire LBA address space almost evenly, while the write requests in Figure 2(b) are concentrated in a limited LBA address space. In the latter case, because the buffer space is not fully utilized, cleanup is triggered frequently, reducing disk I/O performance. Therefore, the data layout scheme of the CMR-based persistent buffer should be redesigned to improve the cleaning efficiency. **Zone-level write-back mechanism. ** Buffer blocks must be periodically written back to accommodate the incoming blocks. In general, the persistent buffer adopts a zone-level write-back mechanism to evict buffer blocks within the same zone that reduces the write amplification generated by cleanup activities [6; 7; 19; 32; 33; 34; 35]. As shown in Figure 4, the RMW operation of the cleanup process consists of three steps: reading valid blocks from the native zone, collecting victim blocks, and writing back the merged blocks. Steps (1) and (3) require only one sequential read and write operation, while the collection of victim blocks in step (2) involves multiple read operations. In particular, the victim blocks are scattered within persistent buffer space, which can further exacerbate the time overhead of collecting them. In the worst case, it takes more than 30 s to write back a zone [6; 7]. Under write-intensive workloads, frequently triggered cleanup activities can cause severe performance degradation on SMR disks. In addition, the spatial locality of the victim can also affect the native zone. In other words, the layout of blocks within the native zone determines to some extent whether future writebacks will trigger RMW operations. This is due to the fact that the victim blocks are scattered (i.e., have weak spatial locality), which corrupts the spatial locality of the native zone and can introduce unnecessary RMW operations in  
Figure 3: The distribution of the write range for block under real MSR workloads. In (**a**,**b**), the x-axis represents the virtual time (i.e., the reference sequence of write requests), the y-axis represents the number of logical blocks accessed by the write request, and each dot represents a logical block. the next cleanup. In summary, the victim collection overhead of the zone-level write-back mechanism and the spatial locality characteristics of the victim are the main factors that affect the efficiency of the cleanup of the persistent buffer. **Our solutions. ** Combined with the analysis of existing studies in Section 2.2, in this section, we further clarify the key factors that affect the efficiency of CMR-based persistent buffers and use the following techniques to implement the proposed strategy: (1) to reduce the write-back frequency of hot blocks, we design a two-phase data block classification method to capture blocks with frequent updates but long periods; (2) to improve buffer cleanup efficiency, we propose a locality-aware buffer space management scheme to isolate blocks with different update frequencies; (3) to reduce the cost of zone-level write-back mechanism, we develop a latency-sensitive garbage collection policy to solve this problem.