274 13th USENIX Conference on File and Storage Technologies (FAST ’15) USENIX Association
the first publicly and widely available file system that
is designed from scratch to optimize performance and
lifetime of flash devices with a generic block interface.
1
This paper describes its design and implementation.
Listed in the following are the main considerations for
the design of F2FS:
• Flash-friendly on-disk layout (Section 2.1). F2FS
employs three configurable units: segment, section and
zone. It allocates storage blocks in the unit of segments
from a number of individual zones. It performs “clean-
ing” in the unit of section. These units are introduced
to align with the underlying FTL’s operational units to
avoid unnecessary (yet costly) data copying.
• Cost-effective index structure (Section 2.2). LFS
writes data and index blocks to newly allocated free
space. If a leaf data block is updated (and written to
somewhere), its direct index block should be updated,
too. Once the direct index block is written, again its in-
direct index block should be updated. Such recursive up-
dates result in a chain of writes, creating the “wandering
tree” problem [4]. In order to attack this problem, we
propose a novel index table called node address table.
• Multi-head logging (Section 2.4). We devise an effec-
tive hot/cold data separation scheme applied during log-
ging time (i.e., block allocation time). It runs multiple
active log segments concurrently and appends data and
metadata to separate log segments based on their antici-
pated update frequency. Since the flash storage devices
exploit media parallelism, multiple active segments can
run simultaneously without frequent management oper-
ations, making performance degradation due to multiple
logging (vs. single-segment logging) insignificant.
• Adaptive logging (Section 2.6). F2FS builds basically
on append-only logging to turn random writes into se-
quential ones. At high storage utilization, however, it
changes the logging strategy to threaded logging [23] to
avoid long write latency. In essence, threaded logging
writes new data to free space in a dirty segment without
cleaning it in the foreground. This strategy works well
on modern flash devices but may not do so on HDDs.
• fsync acceleration with roll-forward recovery
(Section 2.7). F2FS optimizes small synchronous writes
to reduce the latency of fsync requests, by minimizing
required metadata writes and recovering synchronized
data with an efficient roll-forward mechanism.
In a nutshell, F2FS builds on the concept of LFS
but deviates significantly from the original LFS proposal
with new design considerations. We have implemented
F2FS as a Linux file system and compare it with two
1
F2FS has been available in the Linux kernel since version 3.8 and
has been adopted in commercial products.
state-of-the-art Linux file systems—EXT4 and BTRFS.
We also evaluate NILFS2, an alternative implementation
of LFS in Linux. Our evaluation considers two generally
categorized target systems: mobile system and server
system. In the case of the server system, we study the
file systems on a SATA SSD and a PCIe SSD. The results
we obtain and present in this work highlight the overall
desirable performance characteristics of F2FS.
In the remainder of this paper, Section 2 first describes
the design and implementation of F2FS. Section 3 pro-
vides performance results and discussions. We describe
related work in Section 4 and conclude in Section 5.
2 Design and Implementation of F2FS
2.1 On-Disk Layout
The on-disk data structures of F2FS are carefully laid
out to match how underlying NAND flash memory is or-
ganized and managed. As illustrated in Figure 1, F2FS
divides the whole volume into fixed-size segments. The
segment is a basic unit of management in F2FS and is
used to determine the initial file system metadata layout.
A section is comprised of consecutive segments, and
a zone consists of a series of sections. These units are
important during logging and cleaning, which are further
discussed in Section 2.4 and 2.5.
F2FS splits the entire volume into six areas:
• Superblock (SB) has the basic partition information
and default parameters of F2FS, which are given at the
format time and not changeable.
• Checkpoint (CP) keeps the file system status, bitmaps
for valid NAT/SIT sets (see below), orphan inode lists
and summary entries of currently active segments. A
successful “checkpoint pack” should store a consistent
F2FS status at a given point of time—a recovery point af-
ter a sudden power-off event (Section 2.7). The CP area
stores two checkpoint packs across the two segments (#0
and #1): one for the last stable version and the other for
the intermediate (obsolete) version, alternatively.
• Segment Information Table (SIT) contains per-
segment information such as the number of valid blocks
and the bitmap for the validity of all blocks in the “Main”
area (see below). The SIT information is retrieved to se-
lect victim segments and identify valid blocks in them
during the cleaning process (Section 2.5).
• Node Address Table (NAT) is a block address table to
locate all the “node blocks” stored in the Main area.
• Segment Summary Area (SSA) stores summary en-
tries representing the owner information of all blocks
in the Main area, such as parent inode number and its
剩余14页未读，继续阅读
羊羊在努力
- 粉丝: 0
- 资源: 1
我的内容管理
展开
最新资源
- Lombok 快速入门与注解详解
- SpringSecurity实战：声明式安全控制框架解析
- XML基础教程：从数据传输到存储解析
- Matlab实现图像空间平移与镜像变换示例
- Python流程控制与运算符详解
- Python基础：类型转换与循环语句
- 辰科CD-6024-4控制器说明书：LED亮度调节与触发功能解析
- AE particular插件全面解析：英汉对照与关键参数
- Shell脚本实践：创建tar包、字符串累加与简易运算器
- TMS320F28335：浮点处理器与ADC详解
- 互联网基础与结构解析：从ARPANET到多层次ISP
- Redhat系统中构建与Windows共享的Samba服务器实战
- microPython编程指南：从入门到实践
- 数据结构实验：顺序构建并遍历链表
- NVIDIA TX2系统安装与恢复指南
- C语言实现贪吃蛇游戏基础代码
资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！
点击此处反馈
