IMRSim: A Disk Simulator for Interlaced Magnetic Recording Technology

Fig. 2 depicts the architectural overview of IMRSim. The read/write requests initiated by the upper-layer application are routed from top to bottom in Linux’s I/O subsystem. The IMRSim kernel module has the ability to capture and modify the original request (e.g., redirect). Thus, a mapped request is obtained, and then the request is added to the request queue until it is processed on disk.

The IMRSim kernel module contains the following sub-modules: (1) the data layout and management sub-module, which simulates the layout of interlaced track and uses “zone” to manage the track space (“zone” is similar to “TG” (Amer et al., 2011; Wu et al., 2020)), (2) the data placement sub-module, which handles different types of requests (read, write and update) for the simulated IMR disk, (3) the address translation and I/O mapping sub-module, which does the I/O redirection, (4) the availability and statistics collection sub-module, which launches a persistent thread to ensure availability, synchronize meta-data, and collect status information of the simulator. We will introduce them in detail in the following.

It’s worth noting that the bottom track is wider and has a larger data storage density than the top track. Thus, we design the top and bottom tracks with the different data densities. According to previous research (Rottmayer et al., 2006), the data density of the bottom track in IMRSim is about 1.25 times that of the top track.

The RMW process of data read, write and update operations is shown in Algorithm 1. For the update of the data block, we need to judge the properties of the track where the block is located. If the block is on the top track, the update is free; if the block is on the bottom track, the RMW process is required during the update operation. It is worth noting that whether the top track data is backed up in memory or on disk has a greater impact on performance, but such analysis is beyond the scope of this article. In particular, in our implementation, we use page to keep data that needs to be backed up in memory.

Here, we define two helpful functions. The first one is the address translation function ($AT$, e.g., $y=AT(x)$) is responsible for converting the request address into the logical zone ID, the track offset and the block offset triples in the related zone. The second one is its inverse function (denoted as $AT^{-1}$) performs the reverse conversion. The $x$ represents LBA or PBA, and $y$ represents the relative block address, which is represented by a triple ($Zone\,ID$, $Track$ $Offset$, $Block\,Offset$).

As illustrated in Fig. 4, to get the PBA with the given LBA, IMRSim first uses $AT$ to convert the LBA into the managed triple to get the zone ID and block offset ($bo$). Then, there will be two cases:

1) If there is no record corresponding to $bo$ in the MT, it means a new write operation. At this time, IMRSim allocates a new block (with a new block offset, i.e. $nbo$) according to the different track allocation schemes, and then record $bo$ (block offset) to $nbo$ in the MT.

2) If there is a record corresponding to $bo$ in the MT, it means an update operation. Thus, the $nbo$ can be obtained by querying the MT.

Finally, the PBA can be obtained by using $AT^{-1}$.

Note that the address translation triples (ie, y and y)̀ omit the track offset in Fig. 4. This is because, with the $zoneID$ and $nbo$ can uniquely identify the PBA. Currently, we have implemented the classical two phases allocation strategy, and the three phases allocation strategy in IMRSim. Of course, the other multi-phase allocation strategies can be designed as needed. Also, our mapping table may be utilized to implement strategies such as track caching, hot and cold data swap, and track flipping (Wu et al., 2018; Wu et al., 2020).

We add a meta-data area after data storage to record the mapping table and disk statistics. In addition, users can easily add new statistical indicators in IMRSim. In the current version of IMRSim, we record the behavior information of the simulator (e.g., the number of writes that occurred additionally) into memory, and open a persistent thread to periodically flush the collected statistics or the changed metadata to the disk.

To facilitate user interaction with the simulator, we design a command-line user interface. It is a standard C program implemented based on the ioctl system call. The ioctl system call can be easily extended in the kernel, which makes IMRSim highly extensible. The user can use such system calls to flexibly adjust the design parameters and control the behavior of the simulator according to their needs. For example, users can input “./imrsim_util /dev/mapper/imrsim l 5 3” to set the allocation strategy to three-phase allocation.

In the implementation, the interface needs some command parameters to select the required operation. If the input format is wrong, it will notify the user of the wrong format and provide a friendly help interface and a correct input example.

In addition, we implement a quick visualization of IMRSim which cam briefly demonstrate the dynamic process of IMR processing requests. Such visualization can help readers to further understand the track characteristics of IMR. We have collected the I/O traces of a zone during the fio test to realize visualization. As shown in Fig. 5(a), a two-stage IMR zone always allocates the bottom track before the top track when it is empty to process write requests (whether sequential or random). There is always one track spaced apart during the allocation process (the allocated track turns darkgray), as shown in Fig. 5(b).

This section evaluates the performance of two different allocation strategies. We created a 128GB IMR-based HDD and a 128GB CMR-based HDD on a Western Digital’s pure CMR drive (see Table 1). Note that we use the same partition on the CMR drive to ignore the impact of OD/ID differences on performance. In our experiment, we implement different allocation strategies for evaluation as follows: First, we evaluate the performance of IMR two-stage allocation versus three-stage allocation strategies. Second, the typical RMW update strategy is implemented.

We conduct all the experiments on a desktop PC, which is equipped with twelve Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz processors and 16 GB DDR4 DIMM memory, where the operating system is 64-bit Ubuntu 14.10 with Linux kernel 3.16.0. For performance testing, we use fio-3.30 to replay and evaluate four real write-intensive workloads, i.e., hm_0, proj_0, src1_2 and src2_2, collected by Microsoft Research Cambridge (Narayanan et al., 2008). Table 2 provides more details about these workloads including the numbers of read/write requests, the total read/write sizes (GB), and the write ratio. In particular, to better evaluate the performance in handling requests, four write-intensive workloads with the accessed LBAs fitting in the tested disk space (i.e., 128GB).

In the experimental configuration, the number of threads is set to 1, the IO queue depth is set to 32, and the IO engine is set to libaio. In addition, to avoid the impact of kernel cache on the simulator performance, all the I/O requests generated by the test are the direct I/O, by passing the kernel buffer. Moreover, we execute command hdparm -W0 -A0 -a0 to have the HDD cache disabled. One more thing to note, since there are no rewrites operation are incurred if the space usage is less than 55.47% of the disk space (at this point, the first stage has just been allocated). Thus, we use 32 KB (which is close to the average write size of the four evaluated workloads) random write requests to initialized the simulated IMR-based HDD.

1) Write Amplification under Different Space Usages: Fig. 6 shows the write amplification factor with different space usage under the src1_2 workload, where the x-axis denotes space usage of different tested devices and the y-axis represents write amplification factor (i.e., the ratio of the actual total number of writes to the number of write requests). Since the CMR-based HDD (denoted as CMR) uses a cost-free in-place update strategy and does not cause write amplification problems, its write amplification factor is always 1. We use our IMRSim to simulate IMR-based HDD with two stage allocation strategy (denoted as two-stage IMR) and IMR-based HDD with two stage allocation strategy (denoted as three-stage IMR).

It can be clearly observed that, as the space utilization increases, the write amplification factor gradually increases. Also, the write amplification of two-stage IMR is slight larger than that of three-stage IMR. However, as the space utilization increases, the write amplification difference between the two-stage IMR and three-stage IMR is getting smaller.

2) Performance results under different workloads: As shown in Fig. 7, We evaluate total write and read latency and write amplification with different workloads under 80% space usage. Specifically, we reply four real write-intensive workloads (i.e., hm_0, proj_0, src1_2 and src2_2) to collect the experimental results and verify the correctness of our simulator.

Write Perfomance. Fig. 7(a) demonstrates the write performance of three simulated devices under 80% space usage, where the x-axis denotes various workloads and the y-axis represents the write performance in terms of the total write latency (i.e., the total time for executing write requests).

It can be firstly observed that, under four emulated workloads, the simulated IMR-based HDD have a relatively large write performance gap with CMR while the two-stage IMR and three-stage IMR achieve similar write performance. Specifically, CMR outperforms IMR by 12.5x in the hm_0 workload, by 35.6x in the proj_0 workload, and by an average of 28.7x in four workloads. For the comparison of IMR-based HDDs with different allocation stages, two-stage IMR outperforms three-stage IMR in write performance in the hm_0 workload, however it performs worse compared to three-stage IMR in the other three workloads and has an average write performance loss of 0.55x in four workloads.

The experimental result shows that the performance loss brought by the RMW update strategy is very huge, although each update behavior only causes at most two additional read and write operations. In order to analyze the reasons for the huge performance loss caused by RMW, we calculated the write amplification factor of each workload under 80% space usage in the experiment. We count the number of extra writes in blocks and calculate the write amplification factor, and the result is shown in Fig. 7(c). It can be observed that, across four emulated workloads, the additional writes of IMR are at most 1.8x that of CMR. A mere 1.8x difference in write times results in a 28x difference in write performance. This is mainly because mechanical disks consume time in seek and rotation delays, and the RMW process needs to spend extra time on these positioning operations. The extra time is much larger than the data transfer delay. For IMR-based HDDs with different allocation stages, the average extra write times of the two-stage IMR is slightly larger than that of the three-stage IMR, which results in a slightly worse write performance than the three-stage IMR.

Read Perfomance. Fig. 7(b) demonstrates the read performance of three simulated devices under 80% space usage, where the x-axis denotes various workloads and the y-axis represents the read performance in terms of the total read latency (i.e., the total time for executing read requests).

It can be clearly observed that, in four emulated workloads, two-stage IMR and three-stage IMR exhibit read performance close to CMR, as expected. Specifically, the read performance of two-stage IMR is 9.55% slower than that of CMR on average under 80% space usage, and the read performance of three-stage IMR is only 7.98% slower than that of CMR on average. The main reason for the slight difference in read performance between IMR and CMR is that IMR needs to maintain a dynamic mapping table, and different allocation methods will also lead to different block addresses, which in turn affects delays such as seek time.