ZoneTrace: Zone Monitoring Tool for F2FS on ZNS SSDs

The introduction of the ZNS interface avoids the performance limitations associated with the existing block interface in traditional flash-based SSDs. Compared to traditional block-based SSDs, ZNS SSDs organize logical blocks into zones, requiring each zone to be written sequentially. As shown in Figure 1(a), the size of a zone is defined as the total number of logical blocks within the zone. Each zone in the device address space has a write pointer that tracks the next writable LBA within each zone. ZNS SSDs also define a zone capacity attribute for each zone, indicating the number of usable logical blocks in the zone, starting from the first logical block of each zone. The zone capacity attribute is either equal to or smaller than the zone size. Employing zone capacities that differ from the zone size allows for the zone size to remain constant for all zones while optimizing the mapping of a zone capacity to the underlying media characteristics. F2FS and BTRFS [29] are currently the two POSIX compliant file systems that support ZNS SSDs. Although BTRFS currently supports zoned block devices, the support is still experimental [27], while F2FS is relatively mature. Therfore in this study, we choose F2FS as the target file system with ZNS SSDs.

F2FS is a widely adopted file system designed for flash-based SSDs, partitioning the storage space into regions dedicated to random writes for metadata-block and multi-stream sequential writes main data area. As shown in Figure 1(b), a multi-device setup is required for using ZNS SSDs with F2FS to place the metadata blocks on random writable storage. The metadata blocks area contains, Superblock (SP), CheckPoint (CP), Segment Information Table (SIT), Node Address Table (NAT), and Segment Summary Area (SSA), containing necessary information on the file system data layout. F2FS divides the whole volume into fixed-size 2 MB segments. A group of segments is called a section. The number of segments in a section is determined to match the zoned device zone size. For example, with a 128 MB zone size, a section contains 64 segments. By default, F2FS tries to optimize block allocation by allowing some random writes within segments. Nevertheless, to be in full compliance with the zoned block device’s sequential write requirement, F2FS needs to run in Log-structured File System (LFS) mode, which forces only sequential writes to segments and the sequential use of segments within sections.

Several works have been proposed to trace the space management of F2FS for flash-based SSDs. They aim to understand the space management and trace related issues such as file fragmentation within F2FS. File fragmentation refers to the situation where a file consists of several blocks that are not located continuously. File fragmentation has a negative impact on I/O performance, since fragmented files require more management overhead to keep track of the scattered data blocks. Park et al. [28] manipulated F2FS with various predefined fragmentation sizes and fragmentation distances using direct I/O with block-based SSDs. Nevertheless, with F2FS on ZNS SSDs, to be in full compliance with sequential-write constraints of ZNS SSDs, F2FS with zoned storage is forced to use buffered I/O [36] for writes. As a result, when users need to reevaluate how fragmentation size and distances are affected with F2FS on ZNS SSDs, their file manipulation scheme must consider the F2FS buffered I/O scheme with ZNS SSDs. Cho and Kang [6] propose a real-time fragmentation monitoring tool that helps users analyze the ratio of F2FS fragmentation in real-time with visualization. However, their tool is unable to visualize each fragment with the zone concept from ZNS SSDs. Tehrany et al. [35] introduced a tool aimed at aiding users in examining the utilization of F2FS space usage on ZNS SSDs. However, their tool lacks runtime monitoring and visualization capabilities, making it less user-friendly. ZoneTrace overcomes these limitations of related work as summarized in Table 1.

Currently F2FS provides users with a very rudimentary interface that dumps space management information through the /proc file system interface, as shown in Figure 2. This interface is not easily readable by a human, and moreover is lacking the zone concept. Indeed, existing works are unable to visualize each zone’s space usage with F2FS on ZNS SSDs, which is crucial information to understand the data management. Developers need a tool to help them visualize the data that is more intuitive than text-based raw data and monitor zone-based space usage for ZNS SSDs at runtime. Furthermore, existing works are unable to manipulate the storage space due to the buffered I/O scheme for writes when using F2FS on ZNS SSDs. To address these issues, we present ZoneTrace, a runtime monitoring and visualization tool for F2FS on ZNS SSD. ZoneTrace can assist users in understanding the space management in F2FS for each zone of ZNS SSDs. ZoneTrace also provides users with a new scheme for manipulating the fragmentation in F2FS zoned mode and proposes a fragmentation histogram as a fragmentation metric for each file on F2FS with ZNS SSDs.

Figure 3 presents an overview of ZoneTrace. As shown in Figure 3, ZoneTrace is able to trace specific functions and data structures in F2FS and visualize the zone usage in ZNS SSDs accordingly at runtime under the server-client architecture. We first modified f2fs-tools, tools allow users to format, check, repair, and manage the F2FS file system, for retrieving the ZNS device information and the file system layout when mounting F2FS on ZNS SSDs. Then, we implemented an eBPF program that traces update_sit_entry in F2FS and exports the F2FS segment kernel data structure to the user space. eBPF is a powerful and flexible framework in the Linux kernel that allows for the dynamic tracing and manipulation on various kernel events. Our eBPF program traces the updated events and transfers the updated valid bitmap in binary format to the standard output. To enhance the portability our eBPF program, we enable BPF Compile Once—Run Everywhere (CO-RE) that enables the eBPF program to run across different kernel versions and architectures. Third, we also make use of the FIBMAP ioctl system call to query the file mapping of each file and calculate the mapping to zone on ZNS SSDs. A server is implemented to capture the standard output from the ePBF program and the FIBMAP ioctl system call via a pipe command. Based on the information that we capture during file system mounting time, we can calculate and visualize the file mapping. Then, the server transfers the decoded data structure for rendering onto the web browser client via http. To help users evaluate metrics for file fragmentation, we further propose a fragmentation histogram accordingly during runtime. Finally, the client visualizer renders the space management of F2FS in each zone on the ZNS SSD.

ZoneTrace is publicly available via this link: https://github.com/pingxiang-chen/bpf-f2fs-zonetrace.git. The comments in each source file of ZoneTrace contains detailed data structure implementation information. For example, the implementation eBPF program that traces the updated event from F2FS is located at src/bpf/f2fszonetracer.bpf.c and the main function of the eBPF program is at src/bpf/f2fszonetracer.c. The server client visualization architecture is implemented within the folder viewer/

To obtain the corresponding F2FS file system layout on ZNS SSDs, we modify f2fs-tools to obtain structure device_info, which contains the logical data layout of ZNS SSD with F2FS. The device_info includes the start block address, the number of zones, the number of blocks within a zone, and the number of unusable blocks within each zone of the mounted ZNS SSD. With the information above, we can determine the start segment number in F2FS mounted on ZNS SSDs based on Equation (1). Since F2FS aligns the number of segments in a section to match the zoned device zone size, we can determine the number of segments in each section by Equation (2). With the starting segment number of F2FS and the number of segments per zone, we can trace the updated segments in F2FS of each zone, visualizing each zone’s space usage in F2FS on ZNS SSD:To further visualize how F2FS files data layout on ZNS SSDs, we additionally make use of the FIBMAP [20] (stands for “Filesystem Index Block Map”) ioctl system call from Linux. FIBMAP system call is primarily used to query the file system for details about the physical location of data blocks associated with a specific file or range of a file. Figure 4 shows the sample output of the implemented fibmap.f2fs from the f2fs-tools [18] application queries the extent mapping of the file /mnt/f2fs/target_file.png. As shown in Figure 4, the FIBMAP system call returns a list of extents, where each extent represents a contiguous block of data on the storage device. For example, the logical file offset 0 in file /mnt/f2fs/target_file.png is mapped to physical block number 4194304 with a contiguous length of 127 4 KB blocks. Then, we can determine the first extent start block number of the file /mnt/f2fs/target_file.png into zone number on ZNS SSD based on Equation (3), and the block offset in zone based on Fomula 4 and visualize each extent from file mapping with the length information:

Although we use the eBPF to trace the update segment function in F2FS, the limitation of using BPF programs is a lack of portability, since the data structures and types are not guaranteed to be the same between kernel versions. To address the issue, we enable BPF CO-RE [25] for better portability of our program. The Linux kernel should be compiled with both the CONFIG_DEBUG_INFO_BTF and CONFIG_DEBUG_INFO_BTF_MODULES enabled for generating deduplicated BPF-type Format (BTF) [3] type information from the kernel. BTF is a file format that provides better introspection into the program by encoding the type information of a BPF program. By default, F2FS is compiled as a kernel module. We use bpftool to dump required BTF information to a header file with F2FS BTF structures using the following command:

With the generated header and BTF information from the compiled kernel, our BPF program could trace specific F2FS functions and structures with better portability across various platforms.

Figure 5 shows the server client architectures of the visualization module of ZoneTrace. The modified f2fs-tools provides the layout of F2FS on ZNS SSDs with device information. Our eBPF program tracing and fibmap.f2fs from f2fs-tools transfers the updated valid bitmap and the file extent layout in binary format to the standard output. A server intercepts the standard output of the eBPF program, as well as the FIBMAP ioctl system call through the pipe interface. Then, the server decodes the standard output with rendering information to the client web browser, and visualizes the space management of F2FS on ZNS SSDs accordingly.

Due to limited memory size of the client web browser, we are not able to visualize each zone’s bitmap usage simultaneously. Instead, at the client side, we let the user choose the zone to monitor and visualize the selected zone’s segment block bitmap. We display all other zones not chosen by the user at the zone level, indicating which zones are active with colors representing segment type, which enables users to focus on zone monitoring. A server was created to collect update events from the eBPF program in real time and sends the corresponding update that bitmap of the user-selected zone to the client. As shown in Algorithm 1, we used batch processing of multiple events for relieving the runtime overhead and set the time interval to 200 ms. On each update event from eBPF, we check if the number of the updated zone matches the user-selected zone. If it does not match, then we send the updated zone number to the client. If it matches, then we notate the updated segment number and store the updated valid bitmap. In each batch, we dispatch the bitmap for notated segments to the client and clear these notations. This mechanism allows us to provide efficient updates from server to client with light-weight overhead.

Previous work [28] uses direct I/O on F2FS with block-based SSD to synthetically generate file fragmentation. However, in F2FS with ZNS SSDs, F2FS is forced to use buffered I/O [36] for writes. Researchers can not directly apply previous schemes for file system manipulation. To adress this need, we provide new ways to manipulate the file layout with F2FS on ZNS SSDs within the context of the F2FS buffered I/O scheme. First, motivated by previous work [28], we define two metrics frag size and frag distance, which can be visualized with ZoneTrace as shown in Figure 6(a). frag size refers to the size of each fragment, while frag distance denotes the distance between two consecutive fragments. Then, to manipulate the created file from a single zone with F2FS on ZNS SSDs, we create a file with predefined multimedia file extensions such as png, which will be stored in the F2FS cold log. Next, we use sync which flushes file system buffers when certain frag size is copied. For the purpose of generating the frag distance, we create another file that has the size of frag distance, then delete it later to generate the empty distance of the between files. Since ZNS SSDs do not have magnetic heads like traditional hard disk drives, the frag distance between each fragment does not affect the read performance. As a result, we further propose a novel fragment histogram that further helps visualize the distribution of fragment size of each file as the fragmentation metric, as shown in Figure 6(b) for user selected files.

Figure 7 shows a typical snapshot of the ZoneTrace user interface for visualizing the space management of F2FS on ZNS SSDs. ZoneTrace provides users with two separate user interfaces for visualization: the F2FS segment usage, and the F2FS file mapping with fragment histogram. As shown in Figure 7(a), for the F2FS segment usage interface, users can select a zone to monitor, and ZoneTrace shows the corresponding F2FS segments’ valid bitmap within the zone on the left side. Furthermore, in F2FS there are six types of segments for hot and cold data separation by default. As a result, we further label the type of updated segments in the zone with different colors. For example, blue represents cold data segments and red represents hot data segments. Figure 7(b) shows the file mapping visualization interface of ZoneTrace. Users can select a file to inspect, ZoneTrace will highlight the zones containing the selected files. Then, the user can select the highlighted zones of the file, and the left-hand side will show the file mapping layout on the selected zone for further analysis.

To demonstrate the use cases of ZoneTrace, we created a 10 MB file using fio [1] with ranges of issues request block sizes and sync option enable for flushing the file system page cache for generating various level of fragmentation. Users can easily observe and identify each file’s fragmentation in each zones of ZNS SSDs easily with ZoneTrace. Moreover, to model the fragmentation level of each file, Figures 8(d), 8(e), and 8(f) shows the fragmentation histogram of the 10 MB file from ZoneTrace. As shown in Figure 8(f), files with higher-levels of fragmentation will contain more fragments having smaller number of continuous blocks. Figures 8(e) and 8(f) show the fragmentation histogram from ZoneTrace, which contains more contiguous data blocks distribution. To evaluate the effect of different levels of fragmentation F2FS has on ZNS SSDs, we measured the sequential read on the synthetic 10 MB file. As shown in Figure 8(g), in highly fragmented situations, there can be up to a 34% degradation in sequential read throughput. ZoneTrace is able to visualize and assist users with fragmentation histogram to identify issues with the space management of F2FS with ZNS SSDs.

As shown in Figure 9, autonomous vehicles (AVs) require in-vehicle data recording [15], e.g., for future investigation when accidents occur. Furthermore, with the advancement of cloud technology, to improve the Advanced Driver-assistance Systems (ADAS) in AVs, the sensor data generated from AVs must be stored locally (① in Figure 9) and then sent to the cloud (② in Figure 9) later for future reuse in training and refining the ADAS [2, 26, 32].

To emulate the streaming saving scenarios of AVs, we make use of the dd [31] command to sequentially write 10 video streams simultaneously to ZNS SSD formatted with F2FS with .mov file extension. Through ZoneTrace, as shown in Figure 10, we observed that there is a series of fragmentation with multiple video streams when using F2FS with ZNS SSDs, which motivates us to investigate the reasons behind why F2FS stores each stream on ZNS SSDs with a higher level of fragmentation.

As shown in Table 2, F2FS maintains a predefined file extensions list to determine the data type of files. For example, for multimedia files such as videos and images, F2FS treats them as cold data by default, since the files are prone to show write-once and read-only patterns. However, as illustrated in Figure 11, saving multiple cold streams into the same cold zone with ZNS SSD incurs fragmentation. Such fragmentation could lead to read performance degradation when sending the streams back to the cloud. The visualization capability of ZoneTrace has helped us observe fragmentation issues intuitively on ZNS SSDs at runtime.

To demonstrate the read performance degradation due to fragmentation, we emulate the streaming saving with varying number of streams. Each stream is saved with cold data file extensions predefined with F2FS. After the emulation, we later measure the average sequential read throughput of each saved streams. As shown in Figure 12, the average read throughput decreases dramatically as the number of streams due to the increased level of file fragmentation. We further do initial exploration by storing two streams with two different file extensions:.mov and .db with F2FS on ZNS SSDs. By default, the files type such as the database files that tend to be updated frequently are stored as hot data in F2FS. As a result, the video streams with file extensions .mov will be stored within cold zone, the database streams will be stored within the hot zone, which separate the two emulated data streams. Therefore, as shown in Figure 12, separation of saving streams is able to reduce stream fragmentation with F2FS on ZNS SSD, improving the read throughput of the saving streams. For future optimization, a fine grained data placement strategy should be proposed to alleviate the fragmentation issues with F2FS zone mode for storing data streams.

To evaluate the tracing overhead of ZoneTrace, we first use fio with random-write heavy workloads with 16 number of jobs as micro-benchmarks. For macro-benchmarks evaluation, we use YCSB workloads a to f and fileserver and varmail workloads from filebench. Figure 13 shows the normalized overall throughput reported from each benchmarks with the comparison between running with and without ZoneTrace. As shown in Figure 13, although ZoneTrace causes extra CPU and memory usage for runtime tracing, ZoneTrace lead to only an average 4.1% throughput slowdown to the foreground workloads. Since the main goal of ZoneTrace is to assist researchers to analyze space management with F2FS on ZNS SSD with ease as illustrated in Section 4.3, we believe the overhead should be acceptable.