# Leveraging Static and Dynamic Wear Leveling to Prolong the Lifespan of Solid-State Drives
## 4 Performance Evaluation  
### Experimental Environment  
To evaluate the lifespan extension effect of the Greedy-MP policy on SSDs, the SSDSim simulator [11] was employed. Since the SSDSim simulator does not implement wear-leveling policies, representative dynamic wear-leveling policies such as CB, WOGC, along with the PWL static wear-leveling policy, were implemented and compared with Greedy-MP.  
The target SSD was modeled based on previous research [27; 28; 29] as follows (Figure 4): The SSD includes a controller that runs a page-mapping FTL and DRAM, where the FTL's mapping table is stored. The DRAM is used solely for storing the mapping table and is assumed not to be used as a cache for NAND. The SSD is configured with four NAND chips, each independently connected via four parallel channels, which serve as the storage media. Each chip consists of two dies, and each die contains two planes. Each plane includes a total of 911 NAND blocks, with each block comprising 576 NAND pages. Each page is 8 KB in size. The NAND page read, page write, and block erase latencies are 45 us, 700 us, and 4 ms, respectively. The maximum erase count for each block is set at 100; once a block exceeds this limit, it becomes a bad block and can no longer be used. The SSD's overprovisioning is set at 20%, meaning the actual storage capacity is 64.1 GB, while the usable capacity exported to the file system is 51.2 GB.  
The SSDSim simulator receives read and write requests from the file system in sector units, which is the basic unit of read/write operations in a hard disk and is 512 bytes in size. Each request contains information such as the type of request (read/write), the starting sector number, and the number of sectors to be read or written. Using this information, the page-mapping FTL identifies the physical location (chip, die, plane, block, page) of the target sectors for each request. Since write requests are processed as out-of-place updates,  
Figure 4: The internal block diagram of the target SSD.  
they can be sent to any chip, die, and plane. To maximize the SSD's parallel processing capability, a single write request is divided into multiple sub-write requests of page size, which are then distributed across the planes of the idle chip at that time [11]. Once the target plane for each sub-write request is determined, the data are written to a clean page within the plane, and garbage collection is triggered if the number of clean pages in any plane falls below 10% of the total.  
Microsoft Research Cambridge (MSRC) traces [30] were used as the I/O request workloads. Table 1 shows the format of the requests in each trace. The MSRC traces represent the starting position (\"Offset\") and size (\"Size\") of the request in bytes. Since the file system's requests are generated in sector units, both the offset and size are multiples of 512. As mentioned earlier, since SSDSim receives requests in sector units, the \"Offset\" and \"Size\" expressed in bytes were converted into sector numbers and sector counts before being passed to SSDSim.  
Table 2 shows the detailed attributes of the traces. The \"Entire Logical Space\" refers to the size of the entire address space accessed in the trace, including any unaccessed areas (\"holes\"). The \"Read Logical Space\" denotes the size of the address space that has been read at least once. Similarly, the \"Write Logical Space\" denotes the size of the address space that has been written at least once. For example, in the cam01 trace, the size of the entire address space is 15.9 GB, of which only 2.1 GB has been accessed through read requests and 0.7 GB through write requests. In most traces, only a small portion of the entire address space has been written, except for the prn0 trace, where 12.4 GB of the address space was written at least once. Additionally, from the \"R/W Ratio\", it can be observed that cam01 and weba exhibit a read-intensive pattern, while the remaining traces show a write-intensive pattern.