Commit 9268cc3523c120eed04a6ad980753d6e7b82d071
Committed by
Jaegeuk Kim
1 parent
24c366a9ea
Exists in
smarc-l5.0.0_1.0.0-ga
and in
5 other branches
f2fs: update f2fs document to reflect SIT/NAT layout correctly
document to reflect the layout generated by mkfs.f2fs . Signed-off-by: Huajun Li <huajun.li.lee@gmail.com> Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
Showing 1 changed file with 9 additions and 9 deletions Inline Diff
Documentation/filesystems/f2fs.txt
1 | ================================================================================ | 1 | ================================================================================ |
2 | WHAT IS Flash-Friendly File System (F2FS)? | 2 | WHAT IS Flash-Friendly File System (F2FS)? |
3 | ================================================================================ | 3 | ================================================================================ |
4 | 4 | ||
5 | NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, have | 5 | NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, have |
6 | been equipped on a variety systems ranging from mobile to server systems. Since | 6 | been equipped on a variety systems ranging from mobile to server systems. Since |
7 | they are known to have different characteristics from the conventional rotating | 7 | they are known to have different characteristics from the conventional rotating |
8 | disks, a file system, an upper layer to the storage device, should adapt to the | 8 | disks, a file system, an upper layer to the storage device, should adapt to the |
9 | changes from the sketch in the design level. | 9 | changes from the sketch in the design level. |
10 | 10 | ||
11 | F2FS is a file system exploiting NAND flash memory-based storage devices, which | 11 | F2FS is a file system exploiting NAND flash memory-based storage devices, which |
12 | is based on Log-structured File System (LFS). The design has been focused on | 12 | is based on Log-structured File System (LFS). The design has been focused on |
13 | addressing the fundamental issues in LFS, which are snowball effect of wandering | 13 | addressing the fundamental issues in LFS, which are snowball effect of wandering |
14 | tree and high cleaning overhead. | 14 | tree and high cleaning overhead. |
15 | 15 | ||
16 | Since a NAND flash memory-based storage device shows different characteristic | 16 | Since a NAND flash memory-based storage device shows different characteristic |
17 | according to its internal geometry or flash memory management scheme, namely FTL, | 17 | according to its internal geometry or flash memory management scheme, namely FTL, |
18 | F2FS and its tools support various parameters not only for configuring on-disk | 18 | F2FS and its tools support various parameters not only for configuring on-disk |
19 | layout, but also for selecting allocation and cleaning algorithms. | 19 | layout, but also for selecting allocation and cleaning algorithms. |
20 | 20 | ||
21 | The file system formatting tool, "mkfs.f2fs", is available from the following | 21 | The file system formatting tool, "mkfs.f2fs", is available from the following |
22 | git tree: | 22 | git tree: |
23 | >> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git | 23 | >> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git |
24 | 24 | ||
25 | For reporting bugs and sending patches, please use the following mailing list: | 25 | For reporting bugs and sending patches, please use the following mailing list: |
26 | >> linux-f2fs-devel@lists.sourceforge.net | 26 | >> linux-f2fs-devel@lists.sourceforge.net |
27 | 27 | ||
28 | ================================================================================ | 28 | ================================================================================ |
29 | BACKGROUND AND DESIGN ISSUES | 29 | BACKGROUND AND DESIGN ISSUES |
30 | ================================================================================ | 30 | ================================================================================ |
31 | 31 | ||
32 | Log-structured File System (LFS) | 32 | Log-structured File System (LFS) |
33 | -------------------------------- | 33 | -------------------------------- |
34 | "A log-structured file system writes all modifications to disk sequentially in | 34 | "A log-structured file system writes all modifications to disk sequentially in |
35 | a log-like structure, thereby speeding up both file writing and crash recovery. | 35 | a log-like structure, thereby speeding up both file writing and crash recovery. |
36 | The log is the only structure on disk; it contains indexing information so that | 36 | The log is the only structure on disk; it contains indexing information so that |
37 | files can be read back from the log efficiently. In order to maintain large free | 37 | files can be read back from the log efficiently. In order to maintain large free |
38 | areas on disk for fast writing, we divide the log into segments and use a | 38 | areas on disk for fast writing, we divide the log into segments and use a |
39 | segment cleaner to compress the live information from heavily fragmented | 39 | segment cleaner to compress the live information from heavily fragmented |
40 | segments." from Rosenblum, M. and Ousterhout, J. K., 1992, "The design and | 40 | segments." from Rosenblum, M. and Ousterhout, J. K., 1992, "The design and |
41 | implementation of a log-structured file system", ACM Trans. Computer Systems | 41 | implementation of a log-structured file system", ACM Trans. Computer Systems |
42 | 10, 1, 26–52. | 42 | 10, 1, 26–52. |
43 | 43 | ||
44 | Wandering Tree Problem | 44 | Wandering Tree Problem |
45 | ---------------------- | 45 | ---------------------- |
46 | In LFS, when a file data is updated and written to the end of log, its direct | 46 | In LFS, when a file data is updated and written to the end of log, its direct |
47 | pointer block is updated due to the changed location. Then the indirect pointer | 47 | pointer block is updated due to the changed location. Then the indirect pointer |
48 | block is also updated due to the direct pointer block update. In this manner, | 48 | block is also updated due to the direct pointer block update. In this manner, |
49 | the upper index structures such as inode, inode map, and checkpoint block are | 49 | the upper index structures such as inode, inode map, and checkpoint block are |
50 | also updated recursively. This problem is called as wandering tree problem [1], | 50 | also updated recursively. This problem is called as wandering tree problem [1], |
51 | and in order to enhance the performance, it should eliminate or relax the update | 51 | and in order to enhance the performance, it should eliminate or relax the update |
52 | propagation as much as possible. | 52 | propagation as much as possible. |
53 | 53 | ||
54 | [1] Bityutskiy, A. 2005. JFFS3 design issues. http://www.linux-mtd.infradead.org/ | 54 | [1] Bityutskiy, A. 2005. JFFS3 design issues. http://www.linux-mtd.infradead.org/ |
55 | 55 | ||
56 | Cleaning Overhead | 56 | Cleaning Overhead |
57 | ----------------- | 57 | ----------------- |
58 | Since LFS is based on out-of-place writes, it produces so many obsolete blocks | 58 | Since LFS is based on out-of-place writes, it produces so many obsolete blocks |
59 | scattered across the whole storage. In order to serve new empty log space, it | 59 | scattered across the whole storage. In order to serve new empty log space, it |
60 | needs to reclaim these obsolete blocks seamlessly to users. This job is called | 60 | needs to reclaim these obsolete blocks seamlessly to users. This job is called |
61 | as a cleaning process. | 61 | as a cleaning process. |
62 | 62 | ||
63 | The process consists of three operations as follows. | 63 | The process consists of three operations as follows. |
64 | 1. A victim segment is selected through referencing segment usage table. | 64 | 1. A victim segment is selected through referencing segment usage table. |
65 | 2. It loads parent index structures of all the data in the victim identified by | 65 | 2. It loads parent index structures of all the data in the victim identified by |
66 | segment summary blocks. | 66 | segment summary blocks. |
67 | 3. It checks the cross-reference between the data and its parent index structure. | 67 | 3. It checks the cross-reference between the data and its parent index structure. |
68 | 4. It moves valid data selectively. | 68 | 4. It moves valid data selectively. |
69 | 69 | ||
70 | This cleaning job may cause unexpected long delays, so the most important goal | 70 | This cleaning job may cause unexpected long delays, so the most important goal |
71 | is to hide the latencies to users. And also definitely, it should reduce the | 71 | is to hide the latencies to users. And also definitely, it should reduce the |
72 | amount of valid data to be moved, and move them quickly as well. | 72 | amount of valid data to be moved, and move them quickly as well. |
73 | 73 | ||
74 | ================================================================================ | 74 | ================================================================================ |
75 | KEY FEATURES | 75 | KEY FEATURES |
76 | ================================================================================ | 76 | ================================================================================ |
77 | 77 | ||
78 | Flash Awareness | 78 | Flash Awareness |
79 | --------------- | 79 | --------------- |
80 | - Enlarge the random write area for better performance, but provide the high | 80 | - Enlarge the random write area for better performance, but provide the high |
81 | spatial locality | 81 | spatial locality |
82 | - Align FS data structures to the operational units in FTL as best efforts | 82 | - Align FS data structures to the operational units in FTL as best efforts |
83 | 83 | ||
84 | Wandering Tree Problem | 84 | Wandering Tree Problem |
85 | ---------------------- | 85 | ---------------------- |
86 | - Use a term, “node”, that represents inodes as well as various pointer blocks | 86 | - Use a term, “node”, that represents inodes as well as various pointer blocks |
87 | - Introduce Node Address Table (NAT) containing the locations of all the “node” | 87 | - Introduce Node Address Table (NAT) containing the locations of all the “node” |
88 | blocks; this will cut off the update propagation. | 88 | blocks; this will cut off the update propagation. |
89 | 89 | ||
90 | Cleaning Overhead | 90 | Cleaning Overhead |
91 | ----------------- | 91 | ----------------- |
92 | - Support a background cleaning process | 92 | - Support a background cleaning process |
93 | - Support greedy and cost-benefit algorithms for victim selection policies | 93 | - Support greedy and cost-benefit algorithms for victim selection policies |
94 | - Support multi-head logs for static/dynamic hot and cold data separation | 94 | - Support multi-head logs for static/dynamic hot and cold data separation |
95 | - Introduce adaptive logging for efficient block allocation | 95 | - Introduce adaptive logging for efficient block allocation |
96 | 96 | ||
97 | ================================================================================ | 97 | ================================================================================ |
98 | MOUNT OPTIONS | 98 | MOUNT OPTIONS |
99 | ================================================================================ | 99 | ================================================================================ |
100 | 100 | ||
101 | background_gc_off Turn off cleaning operations, namely garbage collection, | 101 | background_gc_off Turn off cleaning operations, namely garbage collection, |
102 | triggered in background when I/O subsystem is idle. | 102 | triggered in background when I/O subsystem is idle. |
103 | disable_roll_forward Disable the roll-forward recovery routine | 103 | disable_roll_forward Disable the roll-forward recovery routine |
104 | discard Issue discard/TRIM commands when a segment is cleaned. | 104 | discard Issue discard/TRIM commands when a segment is cleaned. |
105 | no_heap Disable heap-style segment allocation which finds free | 105 | no_heap Disable heap-style segment allocation which finds free |
106 | segments for data from the beginning of main area, while | 106 | segments for data from the beginning of main area, while |
107 | for node from the end of main area. | 107 | for node from the end of main area. |
108 | nouser_xattr Disable Extended User Attributes. Note: xattr is enabled | 108 | nouser_xattr Disable Extended User Attributes. Note: xattr is enabled |
109 | by default if CONFIG_F2FS_FS_XATTR is selected. | 109 | by default if CONFIG_F2FS_FS_XATTR is selected. |
110 | noacl Disable POSIX Access Control List. Note: acl is enabled | 110 | noacl Disable POSIX Access Control List. Note: acl is enabled |
111 | by default if CONFIG_F2FS_FS_POSIX_ACL is selected. | 111 | by default if CONFIG_F2FS_FS_POSIX_ACL is selected. |
112 | active_logs=%u Support configuring the number of active logs. In the | 112 | active_logs=%u Support configuring the number of active logs. In the |
113 | current design, f2fs supports only 2, 4, and 6 logs. | 113 | current design, f2fs supports only 2, 4, and 6 logs. |
114 | Default number is 6. | 114 | Default number is 6. |
115 | disable_ext_identify Disable the extension list configured by mkfs, so f2fs | 115 | disable_ext_identify Disable the extension list configured by mkfs, so f2fs |
116 | does not aware of cold files such as media files. | 116 | does not aware of cold files such as media files. |
117 | 117 | ||
118 | ================================================================================ | 118 | ================================================================================ |
119 | DEBUGFS ENTRIES | 119 | DEBUGFS ENTRIES |
120 | ================================================================================ | 120 | ================================================================================ |
121 | 121 | ||
122 | /sys/kernel/debug/f2fs/ contains information about all the partitions mounted as | 122 | /sys/kernel/debug/f2fs/ contains information about all the partitions mounted as |
123 | f2fs. Each file shows the whole f2fs information. | 123 | f2fs. Each file shows the whole f2fs information. |
124 | 124 | ||
125 | /sys/kernel/debug/f2fs/status includes: | 125 | /sys/kernel/debug/f2fs/status includes: |
126 | - major file system information managed by f2fs currently | 126 | - major file system information managed by f2fs currently |
127 | - average SIT information about whole segments | 127 | - average SIT information about whole segments |
128 | - current memory footprint consumed by f2fs. | 128 | - current memory footprint consumed by f2fs. |
129 | 129 | ||
130 | ================================================================================ | 130 | ================================================================================ |
131 | USAGE | 131 | USAGE |
132 | ================================================================================ | 132 | ================================================================================ |
133 | 133 | ||
134 | 1. Download userland tools and compile them. | 134 | 1. Download userland tools and compile them. |
135 | 135 | ||
136 | 2. Skip, if f2fs was compiled statically inside kernel. | 136 | 2. Skip, if f2fs was compiled statically inside kernel. |
137 | Otherwise, insert the f2fs.ko module. | 137 | Otherwise, insert the f2fs.ko module. |
138 | # insmod f2fs.ko | 138 | # insmod f2fs.ko |
139 | 139 | ||
140 | 3. Create a directory trying to mount | 140 | 3. Create a directory trying to mount |
141 | # mkdir /mnt/f2fs | 141 | # mkdir /mnt/f2fs |
142 | 142 | ||
143 | 4. Format the block device, and then mount as f2fs | 143 | 4. Format the block device, and then mount as f2fs |
144 | # mkfs.f2fs -l label /dev/block_device | 144 | # mkfs.f2fs -l label /dev/block_device |
145 | # mount -t f2fs /dev/block_device /mnt/f2fs | 145 | # mount -t f2fs /dev/block_device /mnt/f2fs |
146 | 146 | ||
147 | Format options | 147 | Format options |
148 | -------------- | 148 | -------------- |
149 | -l [label] : Give a volume label, up to 256 unicode name. | 149 | -l [label] : Give a volume label, up to 256 unicode name. |
150 | -a [0 or 1] : Split start location of each area for heap-based allocation. | 150 | -a [0 or 1] : Split start location of each area for heap-based allocation. |
151 | 1 is set by default, which performs this. | 151 | 1 is set by default, which performs this. |
152 | -o [int] : Set overprovision ratio in percent over volume size. | 152 | -o [int] : Set overprovision ratio in percent over volume size. |
153 | 5 is set by default. | 153 | 5 is set by default. |
154 | -s [int] : Set the number of segments per section. | 154 | -s [int] : Set the number of segments per section. |
155 | 1 is set by default. | 155 | 1 is set by default. |
156 | -z [int] : Set the number of sections per zone. | 156 | -z [int] : Set the number of sections per zone. |
157 | 1 is set by default. | 157 | 1 is set by default. |
158 | -e [str] : Set basic extension list. e.g. "mp3,gif,mov" | 158 | -e [str] : Set basic extension list. e.g. "mp3,gif,mov" |
159 | 159 | ||
160 | ================================================================================ | 160 | ================================================================================ |
161 | DESIGN | 161 | DESIGN |
162 | ================================================================================ | 162 | ================================================================================ |
163 | 163 | ||
164 | On-disk Layout | 164 | On-disk Layout |
165 | -------------- | 165 | -------------- |
166 | 166 | ||
167 | F2FS divides the whole volume into a number of segments, each of which is fixed | 167 | F2FS divides the whole volume into a number of segments, each of which is fixed |
168 | to 2MB in size. A section is composed of consecutive segments, and a zone | 168 | to 2MB in size. A section is composed of consecutive segments, and a zone |
169 | consists of a set of sections. By default, section and zone sizes are set to one | 169 | consists of a set of sections. By default, section and zone sizes are set to one |
170 | segment size identically, but users can easily modify the sizes by mkfs. | 170 | segment size identically, but users can easily modify the sizes by mkfs. |
171 | 171 | ||
172 | F2FS splits the entire volume into six areas, and all the areas except superblock | 172 | F2FS splits the entire volume into six areas, and all the areas except superblock |
173 | consists of multiple segments as described below. | 173 | consists of multiple segments as described below. |
174 | 174 | ||
175 | align with the zone size <-| | 175 | align with the zone size <-| |
176 | |-> align with the segment size | 176 | |-> align with the segment size |
177 | _________________________________________________________________________ | 177 | _________________________________________________________________________ |
178 | | | | Node | Segment | Segment | | | 178 | | | | Segment | Node | Segment | | |
179 | | Superblock | Checkpoint | Address | Info. | Summary | Main | | 179 | | Superblock | Checkpoint | Info. | Address | Summary | Main | |
180 | | (SB) | (CP) | Table (NAT) | Table (SIT) | Area (SSA) | | | 180 | | (SB) | (CP) | Table (SIT) | Table (NAT) | Area (SSA) | | |
181 | |____________|_____2______|______N______|______N______|______N_____|__N___| | 181 | |____________|_____2______|______N______|______N______|______N_____|__N___| |
182 | . . | 182 | . . |
183 | . . | 183 | . . |
184 | . . | 184 | . . |
185 | ._________________________________________. | 185 | ._________________________________________. |
186 | |_Segment_|_..._|_Segment_|_..._|_Segment_| | 186 | |_Segment_|_..._|_Segment_|_..._|_Segment_| |
187 | . . | 187 | . . |
188 | ._________._________ | 188 | ._________._________ |
189 | |_section_|__...__|_ | 189 | |_section_|__...__|_ |
190 | . . | 190 | . . |
191 | .________. | 191 | .________. |
192 | |__zone__| | 192 | |__zone__| |
193 | 193 | ||
194 | - Superblock (SB) | 194 | - Superblock (SB) |
195 | : It is located at the beginning of the partition, and there exist two copies | 195 | : It is located at the beginning of the partition, and there exist two copies |
196 | to avoid file system crash. It contains basic partition information and some | 196 | to avoid file system crash. It contains basic partition information and some |
197 | default parameters of f2fs. | 197 | default parameters of f2fs. |
198 | 198 | ||
199 | - Checkpoint (CP) | 199 | - Checkpoint (CP) |
200 | : It contains file system information, bitmaps for valid NAT/SIT sets, orphan | 200 | : It contains file system information, bitmaps for valid NAT/SIT sets, orphan |
201 | inode lists, and summary entries of current active segments. | 201 | inode lists, and summary entries of current active segments. |
202 | 202 | ||
203 | - Node Address Table (NAT) | ||
204 | : It is composed of a block address table for all the node blocks stored in | ||
205 | Main area. | ||
206 | |||
207 | - Segment Information Table (SIT) | 203 | - Segment Information Table (SIT) |
208 | : It contains segment information such as valid block count and bitmap for the | 204 | : It contains segment information such as valid block count and bitmap for the |
209 | validity of all the blocks. | 205 | validity of all the blocks. |
210 | 206 | ||
207 | - Node Address Table (NAT) | ||
208 | : It is composed of a block address table for all the node blocks stored in | ||
209 | Main area. | ||
210 | |||
211 | - Segment Summary Area (SSA) | 211 | - Segment Summary Area (SSA) |
212 | : It contains summary entries which contains the owner information of all the | 212 | : It contains summary entries which contains the owner information of all the |
213 | data and node blocks stored in Main area. | 213 | data and node blocks stored in Main area. |
214 | 214 | ||
215 | - Main Area | 215 | - Main Area |
216 | : It contains file and directory data including their indices. | 216 | : It contains file and directory data including their indices. |
217 | 217 | ||
218 | In order to avoid misalignment between file system and flash-based storage, F2FS | 218 | In order to avoid misalignment between file system and flash-based storage, F2FS |
219 | aligns the start block address of CP with the segment size. Also, it aligns the | 219 | aligns the start block address of CP with the segment size. Also, it aligns the |
220 | start block address of Main area with the zone size by reserving some segments | 220 | start block address of Main area with the zone size by reserving some segments |
221 | in SSA area. | 221 | in SSA area. |
222 | 222 | ||
223 | Reference the following survey for additional technical details. | 223 | Reference the following survey for additional technical details. |
224 | https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey | 224 | https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey |
225 | 225 | ||
226 | File System Metadata Structure | 226 | File System Metadata Structure |
227 | ------------------------------ | 227 | ------------------------------ |
228 | 228 | ||
229 | F2FS adopts the checkpointing scheme to maintain file system consistency. At | 229 | F2FS adopts the checkpointing scheme to maintain file system consistency. At |
230 | mount time, F2FS first tries to find the last valid checkpoint data by scanning | 230 | mount time, F2FS first tries to find the last valid checkpoint data by scanning |
231 | CP area. In order to reduce the scanning time, F2FS uses only two copies of CP. | 231 | CP area. In order to reduce the scanning time, F2FS uses only two copies of CP. |
232 | One of them always indicates the last valid data, which is called as shadow copy | 232 | One of them always indicates the last valid data, which is called as shadow copy |
233 | mechanism. In addition to CP, NAT and SIT also adopt the shadow copy mechanism. | 233 | mechanism. In addition to CP, NAT and SIT also adopt the shadow copy mechanism. |
234 | 234 | ||
235 | For file system consistency, each CP points to which NAT and SIT copies are | 235 | For file system consistency, each CP points to which NAT and SIT copies are |
236 | valid, as shown as below. | 236 | valid, as shown as below. |
237 | 237 | ||
238 | +--------+----------+---------+ | 238 | +--------+----------+---------+ |
239 | | CP | NAT | SIT | | 239 | | CP | SIT | NAT | |
240 | +--------+----------+---------+ | 240 | +--------+----------+---------+ |
241 | . . . . | 241 | . . . . |
242 | . . . . | 242 | . . . . |
243 | . . . . | 243 | . . . . |
244 | +-------+-------+--------+--------+--------+--------+ | 244 | +-------+-------+--------+--------+--------+--------+ |
245 | | CP #0 | CP #1 | NAT #0 | NAT #1 | SIT #0 | SIT #1 | | 245 | | CP #0 | CP #1 | SIT #0 | SIT #1 | NAT #0 | NAT #1 | |
246 | +-------+-------+--------+--------+--------+--------+ | 246 | +-------+-------+--------+--------+--------+--------+ |
247 | | ^ ^ | 247 | | ^ ^ |
248 | | | | | 248 | | | | |
249 | `----------------------------------------' | 249 | `----------------------------------------' |
250 | 250 | ||
251 | Index Structure | 251 | Index Structure |
252 | --------------- | 252 | --------------- |
253 | 253 | ||
254 | The key data structure to manage the data locations is a "node". Similar to | 254 | The key data structure to manage the data locations is a "node". Similar to |
255 | traditional file structures, F2FS has three types of node: inode, direct node, | 255 | traditional file structures, F2FS has three types of node: inode, direct node, |
256 | indirect node. F2FS assigns 4KB to an inode block which contains 923 data block | 256 | indirect node. F2FS assigns 4KB to an inode block which contains 923 data block |
257 | indices, two direct node pointers, two indirect node pointers, and one double | 257 | indices, two direct node pointers, two indirect node pointers, and one double |
258 | indirect node pointer as described below. One direct node block contains 1018 | 258 | indirect node pointer as described below. One direct node block contains 1018 |
259 | data blocks, and one indirect node block contains also 1018 node blocks. Thus, | 259 | data blocks, and one indirect node block contains also 1018 node blocks. Thus, |
260 | one inode block (i.e., a file) covers: | 260 | one inode block (i.e., a file) covers: |
261 | 261 | ||
262 | 4KB * (923 + 2 * 1018 + 2 * 1018 * 1018 + 1018 * 1018 * 1018) := 3.94TB. | 262 | 4KB * (923 + 2 * 1018 + 2 * 1018 * 1018 + 1018 * 1018 * 1018) := 3.94TB. |
263 | 263 | ||
264 | Inode block (4KB) | 264 | Inode block (4KB) |
265 | |- data (923) | 265 | |- data (923) |
266 | |- direct node (2) | 266 | |- direct node (2) |
267 | | `- data (1018) | 267 | | `- data (1018) |
268 | |- indirect node (2) | 268 | |- indirect node (2) |
269 | | `- direct node (1018) | 269 | | `- direct node (1018) |
270 | | `- data (1018) | 270 | | `- data (1018) |
271 | `- double indirect node (1) | 271 | `- double indirect node (1) |
272 | `- indirect node (1018) | 272 | `- indirect node (1018) |
273 | `- direct node (1018) | 273 | `- direct node (1018) |
274 | `- data (1018) | 274 | `- data (1018) |
275 | 275 | ||
276 | Note that, all the node blocks are mapped by NAT which means the location of | 276 | Note that, all the node blocks are mapped by NAT which means the location of |
277 | each node is translated by the NAT table. In the consideration of the wandering | 277 | each node is translated by the NAT table. In the consideration of the wandering |
278 | tree problem, F2FS is able to cut off the propagation of node updates caused by | 278 | tree problem, F2FS is able to cut off the propagation of node updates caused by |
279 | leaf data writes. | 279 | leaf data writes. |
280 | 280 | ||
281 | Directory Structure | 281 | Directory Structure |
282 | ------------------- | 282 | ------------------- |
283 | 283 | ||
284 | A directory entry occupies 11 bytes, which consists of the following attributes. | 284 | A directory entry occupies 11 bytes, which consists of the following attributes. |
285 | 285 | ||
286 | - hash hash value of the file name | 286 | - hash hash value of the file name |
287 | - ino inode number | 287 | - ino inode number |
288 | - len the length of file name | 288 | - len the length of file name |
289 | - type file type such as directory, symlink, etc | 289 | - type file type such as directory, symlink, etc |
290 | 290 | ||
291 | A dentry block consists of 214 dentry slots and file names. Therein a bitmap is | 291 | A dentry block consists of 214 dentry slots and file names. Therein a bitmap is |
292 | used to represent whether each dentry is valid or not. A dentry block occupies | 292 | used to represent whether each dentry is valid or not. A dentry block occupies |
293 | 4KB with the following composition. | 293 | 4KB with the following composition. |
294 | 294 | ||
295 | Dentry Block(4 K) = bitmap (27 bytes) + reserved (3 bytes) + | 295 | Dentry Block(4 K) = bitmap (27 bytes) + reserved (3 bytes) + |
296 | dentries(11 * 214 bytes) + file name (8 * 214 bytes) | 296 | dentries(11 * 214 bytes) + file name (8 * 214 bytes) |
297 | 297 | ||
298 | [Bucket] | 298 | [Bucket] |
299 | +--------------------------------+ | 299 | +--------------------------------+ |
300 | |dentry block 1 | dentry block 2 | | 300 | |dentry block 1 | dentry block 2 | |
301 | +--------------------------------+ | 301 | +--------------------------------+ |
302 | . . | 302 | . . |
303 | . . | 303 | . . |
304 | . [Dentry Block Structure: 4KB] . | 304 | . [Dentry Block Structure: 4KB] . |
305 | +--------+----------+----------+------------+ | 305 | +--------+----------+----------+------------+ |
306 | | bitmap | reserved | dentries | file names | | 306 | | bitmap | reserved | dentries | file names | |
307 | +--------+----------+----------+------------+ | 307 | +--------+----------+----------+------------+ |
308 | [Dentry Block: 4KB] . . | 308 | [Dentry Block: 4KB] . . |
309 | . . | 309 | . . |
310 | . . | 310 | . . |
311 | +------+------+-----+------+ | 311 | +------+------+-----+------+ |
312 | | hash | ino | len | type | | 312 | | hash | ino | len | type | |
313 | +------+------+-----+------+ | 313 | +------+------+-----+------+ |
314 | [Dentry Structure: 11 bytes] | 314 | [Dentry Structure: 11 bytes] |
315 | 315 | ||
316 | F2FS implements multi-level hash tables for directory structure. Each level has | 316 | F2FS implements multi-level hash tables for directory structure. Each level has |
317 | a hash table with dedicated number of hash buckets as shown below. Note that | 317 | a hash table with dedicated number of hash buckets as shown below. Note that |
318 | "A(2B)" means a bucket includes 2 data blocks. | 318 | "A(2B)" means a bucket includes 2 data blocks. |
319 | 319 | ||
320 | ---------------------- | 320 | ---------------------- |
321 | A : bucket | 321 | A : bucket |
322 | B : block | 322 | B : block |
323 | N : MAX_DIR_HASH_DEPTH | 323 | N : MAX_DIR_HASH_DEPTH |
324 | ---------------------- | 324 | ---------------------- |
325 | 325 | ||
326 | level #0 | A(2B) | 326 | level #0 | A(2B) |
327 | | | 327 | | |
328 | level #1 | A(2B) - A(2B) | 328 | level #1 | A(2B) - A(2B) |
329 | | | 329 | | |
330 | level #2 | A(2B) - A(2B) - A(2B) - A(2B) | 330 | level #2 | A(2B) - A(2B) - A(2B) - A(2B) |
331 | . | . . . . | 331 | . | . . . . |
332 | level #N/2 | A(2B) - A(2B) - A(2B) - A(2B) - A(2B) - ... - A(2B) | 332 | level #N/2 | A(2B) - A(2B) - A(2B) - A(2B) - A(2B) - ... - A(2B) |
333 | . | . . . . | 333 | . | . . . . |
334 | level #N | A(4B) - A(4B) - A(4B) - A(4B) - A(4B) - ... - A(4B) | 334 | level #N | A(4B) - A(4B) - A(4B) - A(4B) - A(4B) - ... - A(4B) |
335 | 335 | ||
336 | The number of blocks and buckets are determined by, | 336 | The number of blocks and buckets are determined by, |
337 | 337 | ||
338 | ,- 2, if n < MAX_DIR_HASH_DEPTH / 2, | 338 | ,- 2, if n < MAX_DIR_HASH_DEPTH / 2, |
339 | # of blocks in level #n = | | 339 | # of blocks in level #n = | |
340 | `- 4, Otherwise | 340 | `- 4, Otherwise |
341 | 341 | ||
342 | ,- 2^n, if n < MAX_DIR_HASH_DEPTH / 2, | 342 | ,- 2^n, if n < MAX_DIR_HASH_DEPTH / 2, |
343 | # of buckets in level #n = | | 343 | # of buckets in level #n = | |
344 | `- 2^((MAX_DIR_HASH_DEPTH / 2) - 1), Otherwise | 344 | `- 2^((MAX_DIR_HASH_DEPTH / 2) - 1), Otherwise |
345 | 345 | ||
346 | When F2FS finds a file name in a directory, at first a hash value of the file | 346 | When F2FS finds a file name in a directory, at first a hash value of the file |
347 | name is calculated. Then, F2FS scans the hash table in level #0 to find the | 347 | name is calculated. Then, F2FS scans the hash table in level #0 to find the |
348 | dentry consisting of the file name and its inode number. If not found, F2FS | 348 | dentry consisting of the file name and its inode number. If not found, F2FS |
349 | scans the next hash table in level #1. In this way, F2FS scans hash tables in | 349 | scans the next hash table in level #1. In this way, F2FS scans hash tables in |
350 | each levels incrementally from 1 to N. In each levels F2FS needs to scan only | 350 | each levels incrementally from 1 to N. In each levels F2FS needs to scan only |
351 | one bucket determined by the following equation, which shows O(log(# of files)) | 351 | one bucket determined by the following equation, which shows O(log(# of files)) |
352 | complexity. | 352 | complexity. |
353 | 353 | ||
354 | bucket number to scan in level #n = (hash value) % (# of buckets in level #n) | 354 | bucket number to scan in level #n = (hash value) % (# of buckets in level #n) |
355 | 355 | ||
356 | In the case of file creation, F2FS finds empty consecutive slots that cover the | 356 | In the case of file creation, F2FS finds empty consecutive slots that cover the |
357 | file name. F2FS searches the empty slots in the hash tables of whole levels from | 357 | file name. F2FS searches the empty slots in the hash tables of whole levels from |
358 | 1 to N in the same way as the lookup operation. | 358 | 1 to N in the same way as the lookup operation. |
359 | 359 | ||
360 | The following figure shows an example of two cases holding children. | 360 | The following figure shows an example of two cases holding children. |
361 | --------------> Dir <-------------- | 361 | --------------> Dir <-------------- |
362 | | | | 362 | | | |
363 | child child | 363 | child child |
364 | 364 | ||
365 | child - child [hole] - child | 365 | child - child [hole] - child |
366 | 366 | ||
367 | child - child - child [hole] - [hole] - child | 367 | child - child - child [hole] - [hole] - child |
368 | 368 | ||
369 | Case 1: Case 2: | 369 | Case 1: Case 2: |
370 | Number of children = 6, Number of children = 3, | 370 | Number of children = 6, Number of children = 3, |
371 | File size = 7 File size = 7 | 371 | File size = 7 File size = 7 |
372 | 372 | ||
373 | Default Block Allocation | 373 | Default Block Allocation |
374 | ------------------------ | 374 | ------------------------ |
375 | 375 | ||
376 | At runtime, F2FS manages six active logs inside "Main" area: Hot/Warm/Cold node | 376 | At runtime, F2FS manages six active logs inside "Main" area: Hot/Warm/Cold node |
377 | and Hot/Warm/Cold data. | 377 | and Hot/Warm/Cold data. |
378 | 378 | ||
379 | - Hot node contains direct node blocks of directories. | 379 | - Hot node contains direct node blocks of directories. |
380 | - Warm node contains direct node blocks except hot node blocks. | 380 | - Warm node contains direct node blocks except hot node blocks. |
381 | - Cold node contains indirect node blocks | 381 | - Cold node contains indirect node blocks |
382 | - Hot data contains dentry blocks | 382 | - Hot data contains dentry blocks |
383 | - Warm data contains data blocks except hot and cold data blocks | 383 | - Warm data contains data blocks except hot and cold data blocks |
384 | - Cold data contains multimedia data or migrated data blocks | 384 | - Cold data contains multimedia data or migrated data blocks |
385 | 385 | ||
386 | LFS has two schemes for free space management: threaded log and copy-and-compac- | 386 | LFS has two schemes for free space management: threaded log and copy-and-compac- |
387 | tion. The copy-and-compaction scheme which is known as cleaning, is well-suited | 387 | tion. The copy-and-compaction scheme which is known as cleaning, is well-suited |
388 | for devices showing very good sequential write performance, since free segments | 388 | for devices showing very good sequential write performance, since free segments |
389 | are served all the time for writing new data. However, it suffers from cleaning | 389 | are served all the time for writing new data. However, it suffers from cleaning |
390 | overhead under high utilization. Contrarily, the threaded log scheme suffers | 390 | overhead under high utilization. Contrarily, the threaded log scheme suffers |
391 | from random writes, but no cleaning process is needed. F2FS adopts a hybrid | 391 | from random writes, but no cleaning process is needed. F2FS adopts a hybrid |
392 | scheme where the copy-and-compaction scheme is adopted by default, but the | 392 | scheme where the copy-and-compaction scheme is adopted by default, but the |
393 | policy is dynamically changed to the threaded log scheme according to the file | 393 | policy is dynamically changed to the threaded log scheme according to the file |
394 | system status. | 394 | system status. |
395 | 395 | ||
396 | In order to align F2FS with underlying flash-based storage, F2FS allocates a | 396 | In order to align F2FS with underlying flash-based storage, F2FS allocates a |
397 | segment in a unit of section. F2FS expects that the section size would be the | 397 | segment in a unit of section. F2FS expects that the section size would be the |
398 | same as the unit size of garbage collection in FTL. Furthermore, with respect | 398 | same as the unit size of garbage collection in FTL. Furthermore, with respect |
399 | to the mapping granularity in FTL, F2FS allocates each section of the active | 399 | to the mapping granularity in FTL, F2FS allocates each section of the active |
400 | logs from different zones as much as possible, since FTL can write the data in | 400 | logs from different zones as much as possible, since FTL can write the data in |
401 | the active logs into one allocation unit according to its mapping granularity. | 401 | the active logs into one allocation unit according to its mapping granularity. |
402 | 402 | ||
403 | Cleaning process | 403 | Cleaning process |
404 | ---------------- | 404 | ---------------- |
405 | 405 | ||
406 | F2FS does cleaning both on demand and in the background. On-demand cleaning is | 406 | F2FS does cleaning both on demand and in the background. On-demand cleaning is |
407 | triggered when there are not enough free segments to serve VFS calls. Background | 407 | triggered when there are not enough free segments to serve VFS calls. Background |
408 | cleaner is operated by a kernel thread, and triggers the cleaning job when the | 408 | cleaner is operated by a kernel thread, and triggers the cleaning job when the |
409 | system is idle. | 409 | system is idle. |
410 | 410 | ||
411 | F2FS supports two victim selection policies: greedy and cost-benefit algorithms. | 411 | F2FS supports two victim selection policies: greedy and cost-benefit algorithms. |
412 | In the greedy algorithm, F2FS selects a victim segment having the smallest number | 412 | In the greedy algorithm, F2FS selects a victim segment having the smallest number |
413 | of valid blocks. In the cost-benefit algorithm, F2FS selects a victim segment | 413 | of valid blocks. In the cost-benefit algorithm, F2FS selects a victim segment |
414 | according to the segment age and the number of valid blocks in order to address | 414 | according to the segment age and the number of valid blocks in order to address |
415 | log block thrashing problem in the greedy algorithm. F2FS adopts the greedy | 415 | log block thrashing problem in the greedy algorithm. F2FS adopts the greedy |
416 | algorithm for on-demand cleaner, while background cleaner adopts cost-benefit | 416 | algorithm for on-demand cleaner, while background cleaner adopts cost-benefit |
417 | algorithm. | 417 | algorithm. |
418 | 418 |