What is the problem the authors are trying to solve?

The authors want to build a file system designed for Linux and optimized for SSDs.

What other approaches or solutions existed at the time that this work was done?

The baseline file system that the authors compared to was ext4, but there are many file systems available in general. It is not clear whether ext4 had any features that optimized for SSD (or at least improved cases in which performance was bad). But there was lots of work in improving file systems for flash storage going back as early as 2005:

• Buffer Management Scheme for Im-proving Random Writes in Flash Storage (2008)
• YAFFS: Yet Another Flash File System (2004)
• JFFS2: The Journalling Flash File System (2001)
• A Transactional Flash File System for Microcontroller (2005)
• ELF: An Efficient Log-Structured Flash File System for Micro Sensor Nodes (2004)
• NVMFS: A hybrid filesystem for improving random write in nand-flash SSD (2013)
• LAST:locality-aware sector translation for NAND flash memory-based storage systems (2008)
• Flashlight: A lightweight flash file system for embedded systems (2012)
• A flash-memory based file system (1995)
• DFS: A file system for virtualized flash storage (2010)
• LogFS - finally a scalable flash file system (2005)

What was wrong with the other approaches or solutions? What is the authors’ approach or solution?

Compared to other log-structured approaches, F2FS seems to be better tuned. Some of the other approaches also try to identify which data is “hot” or “cold” which can be good, but F2FS’s approach using operator information (write/append) and implicit data properties (such as file type and data format) seems to be more effective; though not as thoroughly evaluated. Some other approaches target particular environments (embedded systems) or types of hardware. These other applications or environments are not targeted by the authors’ approach.

Why is it better than the other approaches or solutions? How does it perform?

Using on-disk layout that is designed to align with NAND flash organization and management, and a new method of indexing inodes and data blocks via an inode map, F2FS appears to achieve up to 2.4X speedup over ext4 on the server system, and up to 2 or 3X speedup over ext4 on the mobile system. There are also significant reductions in amount of data writes (up to 40%) of F2FS compared to ext4 on the mobile system.

It appears that there may be some typos in the paper, but I believe from Figure 8 that, for fileserver operations, F2FS performs significantly better than ext4 when using either F2FS adaptive logging or normal logging. However, when the device is filled up 100% and the iozone workload is run, then ext4 performs better, which is to be expected as it is mentioned that ext4 is an update-in-place file system.

Why is this work important?

This work seems important to me because it pushes the state of the art in some areas that will be important for continuing to extract performance out of file systems for SSDs: the identification/analysis of cold/warm/hot data, data structures that accommodate hardware characteristics in the design–but in a way that shouldn’t be difficult to swap out for an implementation for other hardware as needed, and some investigation of multi-head logging, essentially exploring the scaling of channels to the storage medium.

While the data access patterns are clearly explored in other work, this paper seems to add new perspectives, or additional dimensions, with which to analyze and design interactions between file systems and SSDs. Specifically, the idea of warm data, and the use of data characteristics (file type and data format) to identify data access patterns seems novel. The inode block index design also seems relatively novel, as it is compared to the inode map from LFS, which seemingly has not been replaced by a better index structure before this paper.

3+ comments/questions