SplitZNS: Towards an Efficient LSM-Tree on Zoned Namespace SSDs

We provide a high-level overview of the LSM-tree [46], as shown in Figure 1. LSM-tree is organized as \(n+1\) levels. Each level consists of multiple immutable files (called SSTables) composed of multiple data blocks and index blocks. To support efficient queries, each SSTable and each level (except L0) is sorted.

Read and Write. When writing a key-value pair, LSM-tree first appends it to WAL (Write Ahead Log) for crash consistency and then inserts it into a memtable in the memory (usually an ordered skip-list) for batched writes to the underlying storage device. When the memtable grows over the threshold size, LSM-tree marks it as immutable, flushes it as an SSTable into L0, and deletes the flushed key-value pairs from WAL. To read a key-value pair, LSM-tree first searches the memtables. If the key is not found, LSM-tree will search SSTables level by level. Since each level (except L0) and their SSTables are sorted, the LSM-tree can easily find a key-value pair by searching binarily.

Flush and Compaction. The SSTables of the base level (i.e., L0) are flushed straight from the in-memory memtables. The SSTables of the subsequent levels are formed by LSM-tree compactions that migrate valid key-value pairs from one level to the next. SSTables at the same level have non-overlapping key ranges except L0. To remove duplicate key-value pairs to cut down on read and space amplification, each level has a threshold size that limits the number of SSTables and grows exponentially with the depth of the level. If the total size of SSTables in \(L_{i}\) exceeds the threshold, an SSTable in \(L_{i}\) is selected and sort-merged with SSTables in \(L_{i+1}\), which have overlapping key ranges. Such a process is called a compaction. By compactions, the stale SSTables in \(L_i\) and \(L_{i+1}\) are deleted and new merged SSTables are created.

NAND Flash-based SSDs are sophisticated electronics equipped with multi-level parallelism [24, 25], as illustrated in Figure 2. NAND flash memory allows for read and write operations at the flash page level. Multiple flash pages are grouped together within the NAND flash chips to form an erase block, which is the granularity at which erase operations occur. Flash writes are only permitted on pages that have been erased. Typically, each NAND flash chip is divided into multiple dies, each of which can independently execute memory commands. All dies on each chip have a common communication interface. Each die consists of one or more arrays of flash cells called planes. Each plane is composed of multiple erase blocks, each of which necessiates writing sequentially at the unit of flash pages. To maximize the utilization of parallel chips and deliver the greatest possible throughput, SSD manufacturers usually aggregate erase blocks with the same block ID across all planes into a superblock [7, 22]. Since the block interface allows in-place update on the address space, legacy block SSDs maintain a FTL to bridge the semantic gap between flash memory and the block interface, which has a serious impact on performance [31, 58]. ZNS SSDs expose SSD internals (i.e., superblocks) in the form of zones to mitigate the negative effects of FTL. The address space is partitioned into zones, which are usually mapped to superblocks and must be written sequentially. The current write position is tracked by a write pointer. While ZNS SSDs eliminate device-side GC, they necessitate zone-aware data placement and possibly host-side GC [5].

ZNS SSDs require a log-structured write approach, which can lead to fragmentation and the need for costly garbage collection. Specifically, compactions remove obsolete key-value pairs but leave invalidated SSTables in zones. To purge these invalidated SSTables and maintain sufficient free space, LSM-tree must perform garbage collection by migrating valid data from fragmented zones and resetting them. Without GC, an SSD would only be able to store a limited amount of valid data. We evaluated the space amplification using fillrandom workload (a write-only and uniform workload) from RocksDB micro-benchmark with 32 MiB SSTs on an 80 GiB ZNS SSD. The empirical observation is that there is only 27.2 GiB valid data when RocksDB corrupts due to shortage of space (2.94× space amplification), confirming the necessity of GC.

Modern ZNS SSDs typically feature gigantic zones. The zone capacity of INSPUR NS8600 and ZN540, for instance, are 1440 MiB and 1077 MiB [41, 50], respectively. The reason is that SSDs are equipped with multi-level parallelism [25], which accounts for their superior performance. As shown in Figure 2, an SSD usually consists of multiple channels, each of which is consist of multiple chips. The chip is consist of a number of dies, and each die is comprised of multiple planes. Each plane comprises numerous erase blocks. The independent execution of read, write, and erase operations is feasible across the chips and dies. In order to achieve optimal performance by simultaneously accessing multiple chips, commercial ZNS SSDs form a zone by combining multiple erase blocks from each chip [6, 7, 22, 23, 35].

Specifically, the SSD controller picks an erase block from each plane (i.e., a few erase blocks from each chip) to form a zone, as the widezone illustrated in Figure 2. Once an IO request arrives, it can be divided into multiple sub-requests at the unit of flash page. These sub-requests can be dispatched to separate chips so that they can be processed concurrently. With the advancement of flash memory technologies, such as Multi-Level Cell (MLC) [1] and 3D stacking [42], a flash cell can store more bits, making the erase block size grow. Consequently, the zone size is expanding as well.

Unfortunately, gigantic zones have a significant negative effect on the performance of LSM-tree. Larger zones result in more severe fragmentation, necessitating more data migration to reclaim zones. In addition to wasting I/O bandwidth, data migration might stall foreground writes since free space is not available until data migration is finished. We conduct a quantitative analysis of the performance and the migrated data size for various zone sizes. For a fair comparison, zones with various sizes share identical I/O performance, which is achieved by adjusting the erase block size. To begin, we use FEMU to emulate an 80 GiB ZNS SSD. 50 GiB data is loaded into the database. Then, the overwrite workload (uniform and write-only) from RocksDB’s dbbench is used to write another 10 million key value pairs (16B key and 1 KiB value size) into the database. The overwrite performances of various zone sizes are evaluated. Figure 3(a) and 3(b) shows the results normalized to 128 MiB zone size. The results show that as the zone size increases from 128 MiB to 1,024 MiB, the write amplification from data migration increases by up to 1.9× and the throughput declines by 73%, which confirms the negative effect of significant zone size.

Although manually increasing the SSTable size can help alleviate the impact of significant zone size, the SSTable size is not fixed and usually small under many compaction policies [48, 51]. Simply adjusting the SSTable size is not feasible for these compaction policies. Moreover, to the best of our knowledge, oversized SSTable sizes usually result in high compaction overhead, as is also noted in earlier studies (GearDB [59], LLCompaction [29]) and practical production experience. Specifically, TiKV can use up to 128 MiB SSTables only when compaction-guard (one of its features to reduce compaction overhead based on the characteristic of its upper application) is enabled [51].

The performance decline associated with larger zones can be attributed to the increased amount of data that needs to be migrated before resetting. Figure 3(c) displays the average size of migrated data for different zone sizes. When increasing the zone size from 128 MiB to 1,024 MiB, the average size of migrated data increases from 43 MiB to 386 MiB while the GC count decreases from 298 to 144. This ultimately results in more data migration and slower GC. Sluggish data migration can compete for the IO bandwidth with foreground operations, while slow GC can cause foreground operations to stall, thus resulting a significant decrease in performance.

There have been several attempts to address the problem yet existing approaches have their own set of limitations. Simply reducing zone size cannot tame the challenge. Unlike widezones, smaller zones align to fewer erase blocks [2]. Consequently, the number of chips that process I/O requests is limited, causing a severe performance degradation. Our experimental results (Section 5.4) further confirm this fact. Notice we also achieves least internal mutual interferences as Reference [2] and even more accurately in this experiment from our perspective since we expose the internal interferences of zones and directly allocating chips (Section 4.3) instead of using profiling-based allocation. Lifetime-based data placement [5] places SSTables with analogous lifetimes in the same zone. However, the SSTable’s lifetime is predicted by its level in the LSM-tree, which, from our perspective, is inaccurate, particularly for high-level SSTables. As seen in Figure 4, we track the lifetime of SSTables from various levels in the uniform and skewed (skewness = 0.99) write-only workloads. The experimental setting is same as above. The lifetimes of most L4 SSTables range from approximately 10s to 800s for the uniform workload and range from approximately 10s to 4000s for the skewed workload. We observe that (1) with a higher skewness, the lifetime difference is larger since the SSTables with hot key ranges are involved in compactions frequently; (2) however, in terms of both workloads, the lifetimes of high-level SSTables can be rather short or rather long, confirming that with or without the skewness, the lifetime prediction based on the level of SSTable is difficult to achieve a high accuracy. We also evaluate the workloads with other different skewness (0.8, 0.9, 0.95) and their experimental results show similar trends.

GearDB [59, 61] and Lifetime-Leveling Compaction (LLC) [29] use zone-specific compaction policies to eliminate GC. Nevertheless, their compaction policies result in a greater write amplification and a longer compaction latency (Section 5.3), which hurts the performance. Moreover, both of them prohibit compaction optimizations when selecting input SSTables for compactions since they mandate a certain order of invalidating SSTables. Examples are LDC [11], which take into account compaction granularity; LevelDB [34], which takes into account the number of times an SSTable’s seek operation failed; and RocksDB [8, 10, 19], which takes into account the SSTable’s age and overlapping ratio. These optimizations cannot co-exist with GearDB or LLC.

The aforementioned analysis yields the following insights, which motivate the design. First, a smaller zone size can alleviate GC. By assigning a zone to a small number of erase blocks managed by a single chip, the zone size can be drastically decreased. However, it leads to underutilized parallelism since I/O requests to these small zones are executed one at a time by a single chip, resulting in a significant decline on I/O performance. Consequently, the second insight is that by using the multi-level structure of LSM-tree, we can efficiently mitigate the negative effect of reduced zone size. Moreover, we can accelerate the performance of these small zones by enhancing parallelism utilization. Based on these insights, we propose SplitZNS, which incorporates different zone sizes into LSM-tree on ZNS SSDs.

Figure 5 provides a high-level overview of SplitZNS (red parts are modules modified compared to conventional RocksDB and ZenFS). We modify the zone management and GC module to support subzones and splitzones. In addition, we adapt Linux Kernel [39] and LibZBD [18] to support splitzone and subzone state transitions. We reuse and extend the original FTL to deliver I/O requests at the device level and implement SubZone Ring, Read Prefetcher, and Read Scheduler to enhance the performance.

In this section, we present two new concepts, splitzone and subzone. The essential difference between splitzone and widezone is that splitzone modifies the zone to chip mapping of widezone, as shown in Figure 2. Within a widezone, zone is mapped to a superblock composed of all chips. Within a splitzone, however, zone is divided into a number of subzones, each of which is mapped to a single chip.

In order to support the management of splitzones and subzones, the zone state machine is modified and some new commands are introduced, as shown in Figure 6. SPLIT command is introduced to convert an empty widezone to a splitzone. The newly converted splitzone is in the open state and contains \(N_{chip}\) empty subzones. Our zone allocator, which will be described in Section 4.3, assigns these free subzones to incoming SSTables. Like conventional widezones, each open splitzone consumes an active token and an open token. When all subzones of a splitzone are inactive (i.e., either empty or full), the splitzone can be deactivated with the FINISH command. In particular, when all subzones of a splitzone are empty, the splitzone can be converted into an empty widezone by the RESET command. Upon deactivating an open splitzone, the consumed active and open token can be released. The state transitions of splitzones and subzones are only initiated by direct host commands, which is a little different from widezones. Once a write request goes to a subzone, this subzone enters automatically into the open state from the empty state; when the host finished writing an SSTable, the subzone is finished; when SSTables are deleted, the subzones are reset with MERGE command.

Despite that partial zone reset (i.e., subzone reset) is not supported in the current ZNS specification, it is feasible from the internal view of SSD. On the device side, zones are superblocks, which are aggregated of erase blocks from multiple chips. A zone reset is built of numerous erase block erasures, as the erase block is the smallest unit of erasure. It is feasible to erase simply a single erase block. Several prior block-interface SSD studies, for instance, employ chip-level GC, where erase blocks are erased at the unit of \(N_{chip}\) flash blocks [21, 36, 57]. The only involved hardware overhead is the additional memory capacity to store the mapping table from subzones to erase blocks. The overhead is acceptable since the mapping table is at the unit of subzones. For a 1 TiB ZNS SSD with 32 MiB subzones, the number of mapping table entries is 32,768 and each entry occupies 8B (4B for the subzone ID and 4B for the erase block ID), which means the total memory capacity overhead is 256 KiB. Hence, the hardware overhead introduced by partial erasure use is acceptable.

There is an apparent tradeoff between data migration and utlization of parallelism for splitzones. Splitzones can decrease data migration owing to their smaller subzones, however, their low parallelism may cause a considerable performance decline. In this section, a policy selectively use various zones is introduced to tackle the dilemma. In short, for low-level (\(L0, L1, L2, L3\)) SSTables, widezones (i.e., large zones, as shown in Figure 2) and lifetime-based data placement are combined to provide high performance and alleviate GC; for high-level SSTables (L4 and above), smaller subzones are used to minimize the cost of GC. Notice Li means the ith level of the LSM-tree, as shown in Figure 1.

This technique is founded on two observations. (1) First, lifetime-based data placement is only inefficient for high-level SSTables. We collect statistics in terms of the lifetime of SSTables from various levels. The result demonstrates that the lifetime varies from nearly 0s to 100s for the low-level SSTables and from 10s to 800s for the high-level SSTables (L4), as is shown in Figure 4. The observation is that the lifetime prediction for low-level, short-lived SSTables is accurate. Thus, lifetime-based data placement is effective for their purposes. However, the lifetime prediction for SSTables at higher levels is inaccurate, making lifetime-based data placement inefficient. (2) Second, small zones may result in severe write stalls because their inferior performance makes compactions slower, which is confirmed by experiments in Section 5.4.2. As mentioned before, to write new key-value pairs, LSM-tree must maintain sizeable free space in memory by flushing memtables. If memtables are flushed slowly, writes may stall, leading to poor performance. Flushing a memtable requires L0 to reserve sufficient free space, thus L0 should also be compacted into the next level as quickly as possible. The lower the level, the greater the impact. Therefore, low-level SSTables should be stored in widezones to avoid write stalls for the same reason. For high-level SSTables which have a gentler impact on foreground writes, subzones are superior choices. Combining these considerations, SplitZNS uses splitzones and subzones merely for high-level SSTables.

Three points should be taken into care to implement a zone allocator which selectively allocates various zones. (1) First, the allocator should allocate the same widezone for SSTables with the equal lifetime (i.e., lifetime-based data placement). Since a splitzone cannot be used mixed with widezones, it must be guaranteed that there are sufficient widezones to avoid shortage of free space for low-level SSTables. Fortunately, the widezones are merely for low-level SSTables, which occupies limited storage space. Hence, a hard limit is set on the maximum number of splitzones (60% of the number of total zones in our case). If the limit is reached, like lifetime-based data placement, the allocator simply allocates widezones for SSTables based on their lifetime. (2) Second, the allocator should be capable of exploiting the parallelism. Remember that subzones within the same splitzone are mapped to independent chips. To leverage this characteristic, a greedy policy is employed to design the zone allocator. When allocating a subzone, SplitZNS always picks a subzone from the splitzone whose capacity usage is the highest (i.e., the number of the full subzones is the highest). Such a policy is favorable for balancing the number of subzones managed by each chip, thus making IO requests to subzones experience the least IO interferences. (3) Besides, in order to further consolidate this optimization, we propose a chip allocator at the device-side, which allocates chips in a round-robin manner. This device-side chip allocator coordinates with the host-side zone allocator to enable the host to be aware and capable of exploiting the SSD internal parallelism. To implement such a round-robin chip allocator, an atomic counter is introduced. The counter iterates from 0 to \(N_{chips}\) (the number of chips), and starts from 0 again. When a write request to an empty subzone arrive at the device, this chip allocator assigns a chip, whose number corresponds to the counter value, to this subzone. Then, this counter is incremented atomically. If this allocated chip has been allocated before to some other subzone within the same splitzone, the allocator just repeats the procedure until it finds an appropriate chip. It is ensured that a chip can be allocated for this subzone since a splitzone is divided into \(N_{chips}\) subzones so each subzone within the same splitzone can be allocated a unique chip.

Since we focus on optimizations on GC caused by compactions, we mainly discuss the performance (throughput and latency) affected by background activities (i.e., compactions and GC). The results include the throughput and latency in the write-only, write-intensive workloads and the read-intensive workloads after the write bursts (i.e., right after loading), as shown in Figure 9 (normalized to LDP) and Figure 10, which leads us to the following conclusions. (1) First, SplitZNS effectively mitigates the effects of GC. Compared to LDP, SplitZNS delivers 2.77× the overwrite throughput and 1.79× the YCSB-A throughput. This is because SplitZNS reduces background data migration because it stores SSTables in subzones and resets subzones without data migration when SSTables are invalidated. (2) Second, compared to the zone-specific compaction policies Gear and LLC, SplitZNS obtains 3.55×, 2.68× throughput for overwrite workload and 1.63×, 1.23× throughput for YCSB-A workload. This is because Gear and LLC triggers many more compactions, which consumes more I/O bandwidth and hence impairs the performance. (3) Third, SplitZNS also improves the performance for workloads dominated by read operations. For instance, SplitZNS shows 1.16×, 2.05×, and 1.11× better throughput for readrandom and 1.29×, 1.21×, and 1.07× better throughput for YCSB-C. This is because background GC for LDP and compactions for Gear and LLC have quite an impact on foreground queries. (4) Fourth, we notice that SplitZNS obtains a greater performance advantage over Gear and LLC in terms of uniform workloads. This is due to the fact that Gear’s and LLC’s compaction policies remove duplicate key-value pairs more efficiently than the Min-Overlapping-Ratio rule employed by LDP and SplitZNS. After loading the database with a skewed zipfian key distribution, SplitZNS and LDP has a greater number of SSTables, resulting in a lower performance. However, SplitZNS stills shows performance advantage over them. More importantly, SplitZNS is compatible with other optimizations on compaction policy, whereas Gear and LLC cannot be integrated with them. (5) Finally, SplitZNS achieves much lower tail latency in terms of both reading and writing. For example, SplitZNS’s reduces 57.2% P99, 52.8% P99.9 overwrite latency and 43.1% P99, 43% P99.9 readrandom latency compared to LDP. In terms of skewed workloads, SplitZNS reduces 39.2% P99 read latency for YCSB-C workload, 39.6% P99 write latency and 24.9% P99 read latency for YCSB-A workload. Compared to Gear and LLC, the experiments show similar trends. These results reveal that by minimizing data migration and employing a more appropriate compaction policy, SplitZNS not only provides higher throughput but also more stable service (i.e., lower tail latency).

In this section, we analyze data written from LSM-tree and GC, respectively. We choose YCSB-A as the analyzed workload. Figures 11 and 12 show the results. -D means device writes and -U means user writes (i.e., writes from compactions and flushing memtables). We can make the following observations. First, the size of data written by user for LDP and SplitZNS are equal. This is because LDP and SplitZNS share the same compaction policy. LSM-tree writes more data in Gear and LLC since their compaction policies incur a greater write amplification. Their background compactions consume much more I/O bandwidth and thus affect the overall performance, which explains why they exhibit longer tail read latency. The interesting point is that Gear and LLC still show better performance in terms of skewed workloads (i.e., YCSB workloads). The reason is that their compaction policies clean duplicate key-value pairs more efficiently, particularly for skewed workloads which have fewer unique keys compared to uniform workloads. Compared to SplitZNS and LLCompaction, their LSM-tree are smaller and have fewer SSTables after YCSB-L workload (37.38 GiB and 2509 files for Gear, 36.41 GiB and 2451 files for LLC, 41.95 GiB and 2,953 files for LDP, 41.97 GiB, and 2,873 files, for SplitZNS). With identical parameters, a smaller LSM-tree usually exhibits higher performance since it triggers fewer compactions when writing and searches fewer SSTables when processing queries.

In order to unveil the detailed information of SplitZNS, we break down the performance gain through applying each technique one by one and collect statistics for various internal metrics, including the amount of compaction stalls, the IO performance during compactions and the flash chip utilization. We choose the overwrite and read random workload, which are severely affected by more compactions and GC compared to other workloads, to illustrate the performance gain breakdown clearly. The results under other workloads have similar trends. native corresponds to employing small zones for all SSTables. Notice we also use the subzone allocator and chip allocator to alleviate inter-zone inference. +diff corresponds to employing small zones only for high-level SSTables (level > 3). +SZR corresponds to leveraging SubZone Ring to accelerate write operations on subzones. +RP corresponds to leveraging Read Prefetcher to exploit parallelism for read operations. +RS corresponds to leveraging Read Scheduler to prevent query being blocked by compactions.

Since LSM-tree is designed for HDD at the very beginning, WiscKey [43] proposes key value separation to reduce the write amplification of LSM-tree based on the observation that the random read performance of SSD is much better than that of HDD. WiscKey stores only keys in LSM-tree and stores values in append-only logs called vLogs to reduce the size of LSM-tree and alleviate compaction overhead. To validate SplitZNS’s advantage over WiscKey, we conduct an experiment with YCSB-A to compare them. SplitZNS uses the legacy LSM-tree. The WiscKey implementation is from RocksDB’s integrated blobdb, which is believed to outperform the original WiscKey. KV separation is evaluated on both ZNS SSD and block SSD. The block SSD is emulated by FEMU with the equivalent hardware configuration and its over-provision space for GC is 20%. In the experiment, the key size is 64B and the value size vary from 200 B to 1 KB. The rest of experimental setting is equivalent as Section 5.2. Figure 17 shows the results normalized to KV separation on the block SSD. Compared to KV separation on block SSD and ZNS SSD, SplitZNS achieves up to 1.7× and 1.3× performance, which demonstrates SplitZNS’s effectiveness. The observation is that smaller the value size, larger the benefit of SplitZNS. The reason is that smaller value size results in more write overhead [12] and GC overhead of value logs. Besides, since the number of key value pairs increases, the size of LSM-tree (stores only keys) also increases, which increases the IO overhead as well.

LSM-tree has been one of the cornerstones of key-value stores. Since it is first proposed decades ago, there have been many efforts to optimize its performance from a set of aspects. dCompaction [47] delays a compaction until multiple SSTables can be merged together. PebblesDB [48] use partitioned tiering design with vertical grouping to reduce write amplification. MatrixKV [60] exploit emerging non-volatile memory to boost the LSM-tree performance. Vigil-KV [32] achieves consistent ultra-low latency via integration with SSDs with Predictable Latency Mode (PLM) [16] interface. Some works [27, 55, 56] aggressively implement an LSM-tree at the firmware level. These works are orthogonal to SplitZNS and complement it.

Fast ZNS SSDs spur researchers to build new ZNS-based storage systems. ZenFS [4, 5] provides a filesystem plugin for RocksDB to enable LSM-tree with the ability to leverage the advantages of ZNS SSDs. To alleviate GC for LSM-tree on ZNS SSDs, LLC [29] proposes a novel compaction policy and CAZA [33] proposes a zone allocation policy, both of which similarly leverage the difference of SSTable lifetime based on key ranges. For ZNS SSDs with only small zones, ZNS-MQ [2] detects the internal interferences of zones through profiling and allocates suitable zones for upper applications. In Section 5.4, we prove that SplitZNS achieves higher performance by tighter integration with LSM-tree. ZNSwap [3] optimized Linux swap memory subsystem by exploiting the advantages of ZNS SSDs. Tehrany et al. [49, 50] systematically evaluate various systems on ZNS SSDs. ZonedStore [44] uses ZNS SSDs to build a concurrent cache system for cloud data storage. Choi, Gunhee et al. [15] borrow the idea from LSM-tree and propose a novel and general-purpose garbage collection scheme. Li, Jinhong et al. [37] proposes a hybrid zoned storage key-value system (i.e., using ZNS SSDs as the performance layer and SMR disks as the capacity layer). ZNS+ [23] proposes a new log-structured-filesystem-aware ZNS interface which offloads the data copy operations to the SSD to accelerate filesystem performance. These works reveal the future directions and possible opportunities for ZNS study, which are in-depth and thought-provoking.

Key-value separation, which stores only keys in LSM-tree and stores values in append-only value logs (vLogs) is proposed as a means of accommodating the increased performance of random reads for SSDs [12, 38, 43]. The introduction of ZNS poses novel challenges for key-value separation. The size of vLog, akin to zone size, has the potential to exert a noteworthy influence on the performance, which is possible to be addressed through SplitZNS. However, the GC process of vLogs differs from the compactions and the lifetime of vLogs is different from those of SSTables. Consequently, the acceleration techniques that were closely associated with the traditional LSM-tree may be rendered obsolete. Moreover, it has been observed that the efficacy of key-value separation is comparatively lower when dealing with workloads comprising of values of small sizes [12] and workloads that are predominantly dominated by range queries [38]. In order to address these challenges, we should pursue a meticulous redesign of SplitZNS, which is part of our future work.

Although SplitZNS erases blocks separately, the existing wear-leveling (WL) techniques [45] are compliant with SplitZNS to guarantee the SSD’s the lifetime. Similar to SplitZNS, recent studies on wear leveling [14, 54] also erase blocks separately, and a real ZNS SSD also erases blocks separately when resetting zones, which confirms that SplitZNS imposes an insignificant impact on wear leveling. Since the comprehensive parameters and statistics such as the initial P/E cycles for erase blocks, the P/E cycles threshold to enable wear leveling, and the P/E cycles distribution pattern are not available for us, conducting a systematic evaluation is currently challenging. It will be incorporated into our future efforts.