# ReZNS: Energy and Performance-Optimal Mapping Mechanism for ZNS SSD
## 2 Background  
Nowadays, NAND flash-based solid-state drives (SSDs) play a crucial role in various environments and are very popular due to attractive benefits compared with hard disk drives (HDDs): low power consumption, high performance, and high density [30; 31; 32; 33; 34; 35]. In addition, advancements in flash density technology (e.g., MLC, TLC, and QLC) are significantly reducing the cost gap between HDDs and SSDs [36; 37; 38]. The internal architecture and characteristics of SSDs are well-known: (1) they are essentially composed of NAND flash memory; (2) read and write operations are handled in page granularity, and erase operation is performed in block granularity; (3) _erase-before-write_, which requires that an entire block should be erased before over-writing any page in that block; (4) the total number of erase counts is limited (called lifespan); (5) a relatively poor performance for random write patterns [39; 40; 41; 42; 43]. To hide the aforementioned unique features, a typical SSD includes both a special software, called a flash translation layer (FTL), to handle the mapping table between the logical block address and physical block address, and a special job, called garbage collection (GC) [44; 45; 46].  
Meanwhile, the performance of random writes in SSDs still remains a critical concern. In addition, many researchers and engineers have reported that random writes can hurt the limited lifespan by triggering extra erase operations [47; 48; 49]. There are numerous research and commercial efforts to improve the performance of random writes so far. Researchers have focused on the storage stack (e.g., page cache, file system, and block I/Os), and they proposed new mechanisms and algorithms to enhance the performance of random writes. For example, F2 FS is one of the flash-friendly file systems, and it follows the basic rules of a log-structured filesystem (LFS) to handle all write requests in sequential order [50]. Some researchers have focused on the NVMe interface and internal architecture of the traditional SSDs. As a result, zoned namespace (ZNS) SSDs have recently emerged as a new type of SSD device; it fundamentally addresses the issues about random writes in the hardware layer.  
Figure 1 shows the internal architecture of ZNS SSDs in detail. The zone is the basic building component of ZNS SSDs. In ZNS SSD, consecutive flash blocks are grouped into the same size to isolate the address space in zone granularity [19]. An application using ZNS SSDs must create its own zone before issuing write requests (we call the allocated zone for applications \"_open zone_\" in this paper). In an open zone, data must be placed in sequential order, and the data are then cleared by a zone-reset command that is triggered by the host when the zone becomes obsolete. Meanwhile, ZNS SSDs never require a huge room for a mapping table (i.e., FTL) in that a write pointer dedicated to a zone indicates the position for the next write request.  
Unfortunately, partitioning the internal space into isolated zones incurs a new challenge: wasting capacity in regions that are no longer used. For instance, let us assume that all available zones are opened, and each zone fills about half of the capacities and then leaves in an idle state without triggering the zone-reset command. In this case, any write requests of a new zone cannot be serviced even though ZNS SSD has sufficient free space because there is no mechanism to dynamically reduce the zone's capacity. Consequently, half of the total capacity on ZNS SSD is unintentionally wasted. On the other hand, it is assumed that the zone-reset command is called upon after performing small write requests. Since the command erases entire flash blocks belonging to a zone at once, not-yet-used flash blocks are unnecessarily erased. In this case, flash blocks are gradually damaged with repeated erase operations and ZNS SSD requires more power to handle it. This motivates us to design a practical mechanism for ZNS SSDs.