Flash Friendly File System (F2FS)

J

Jarret W. Buse

Guest
Flash Friendly File System (F2FS)

The Flash Friendly File System (F2FS) is a file system created by Samsung. It was released with Linux kernel 3.8 in February 2013.

The free space is stored in a bitmap file. The bitmap file is a set of bits, each representing a block of the storage unit. If the block is unused, the bit is set to show it is unused. When a block is used, the bit is set to show its status as used. The files and directories are tracked in a table.

The maximum file size is 3.94 TB with a maximum volume size of 16 TB. Long File Names (LFN) are used which can be up to 255 characters.

The name sounds like it is for flash-style drives such as SD cards, flash hard disks and the like. These storage units are referred to as NAND (NOT AND), which is a type of logic circuit gate. NAND storage units, SD cards and similar, can store a higher amount of data than other logic circuit gates, such as NOR (NOT OR). It can be used on any type of storage unit, but it has extra functions for flash memory. That is, the F2FS has its own built-in Flash Translation Layer (FTL).

The FTL is used to translate a sector based file system such as FAT32, EXT4, etc. to a flash memory card. Flash memory cards do not have cylinders, heads or sectors. The NAND devices do not require power to retain the data stored within them. To emulate a standard hard disk layout, the FTL is used to allow the emulation without it being needed to be coded within the file system. FTL has a built-in algorithm to manage wear leveling. With these types of devices, each bit can only be overwritten a number of times before the bit space is unusable or 'bad'. Some sources have claimed around 100,000 writes/erases per bit. FTL also helps when a write is being performed, but not completed, and the system is reset (or the flash drive removed). If the data is not written then the original state of the data still exists. If the write was completed, then the new data is present.

The FTL incorporated in F2FS does not manage wear-leveling since this is usually built-in to the flash drive itself. The FTL in F2FS allows for a bulk writes to flash drives. Bulk writes is when the system caches the data and writes a lot of data at once which is more time saving. F2FS FTL allows for six parallel writes. These six sections are discussed a little later.

F2FS supports Online Defragmentation for helping storage units that have a fragmentation issue. Fragmentation can slow down performance when reading/writing data to a fragmented storage unit.

F2FS has the ability to perform a file system check (fsck) only when offline, or unmounted. Data integrity is important with all file systems. Data integrity can be damaged by things such as bit rot.

NOTE: Bit rot occurs when a bit loses its value. This can vary by media. Magnetic media can lose the magnetic orientation or intensity. The magnetized areas can move. The movement is from the spinning of the disk causing centripetal force to move the magnetized spaces. The magnetic intensity can diminish over time causing a ‘1’ to be read as a ‘0’. Devices which use an electrical charge can slowly lose the charge over time. Optical disks such as DVDs and Blue-Rays are not resistant to bit rot. The aluminum layer in CDs and DVDs are prone to oxidize by ultra-violet light (being in the sun). Bit rot on an optical disk looks like a coffee stain on the disk under the clear lacquer. Also, there can appear small clear holes which allow light through the media. Usually the CD, DVD and Blue-ray oxidation is referred to as Disk Rot.

When an F2FS volume is created, there is a Superblock created for the volume with two copies maintained on the volume. Each volume is separated into six sections containing each of the following:

  • Checkpoint – file system information such as bitmaps for Segment Information Table and Node Address Table. This is a form of metadata Journaling
  • Segment Information Table – valid block counts and block validity
  • Node Addressing Table – table of node blocks in data area
  • Segment Summary Area – owner information of node and data blocks in data area
  • Data Area – space used to store data files or the normal storage area of files

The six sections just mentioned are where the six parallel writes are done. Data can be written to each section in parallel, or all at once. If data is only being written to one section, then the writing is performed at normal speed. The more sections being written, the faster the write since they are done at once.

When updates are needed to the Segment Information Table and/or the Node Addressing Table, the updates are stored. The writes are performed when a checkpoint is made. If the modifications are considered too small, they are Journaled with the checkpoint entry.

The future of F2FS proposes Offline Resizing and data compression, as well as others.
 

Attachments

  • slide.jpg
    slide.jpg
    18.4 KB · Views: 62,110


Really tempting isn't it? You may want to wait for a stable release.
 
Let me know how well it works for you. I haven't tried to see how fast the parallel copying can be.
 
Hi Jarret,

Nice attempt in explaining F2FS.

>> Some sources have claimed around 100,000 writes/erases per bit.

Actually this is based on the flash part technology being used. The number you mentioned here is applicable for SLC. However for MLC and TLC, it will be typically 10k to 1 k.

>> The six sections just mentioned are where the six parallel writes are done. Data >> can be written to each section in parallel, or all at once.

Due to inherent limitations of flash, write to physical nand pages cannot be done in parallel. By any chance do you mean, F2FS writes data from these sections in round robin fashion, making it appear as parallel virtuallly?
 
I saw that the number of writes for a flash drive are different depending on the source. I checked a few different sites and went with the values most used.

All the resources I found on F2FS stated that the writing was done in parallel. I understand that this may not be the case with a lot of hardware limitations. With faster flash systems, even data written in a round robin fashion could seem fast enough to be considered near parallel. Of course, the parallel ability may be there when the hardware catches up with the ability of the F2FS drivers. I haven't checked the USB 3.0 specs, but you would think it would eventually be possible for the hardware.
 

Members online


Top