In very simple approximation a flash file system is designed for storing files on flash memory–based storage devices, such as NAND memory chips. Although they share the same name with the rest of the file systems such as FAT, NTFS, exFAT, HFS or EXT, the flash file systems are optimized for the characteristics of flash memory. At this point a fair question might be: Why do we need a flash file system when there are already so many other files systems in use?
To answer this question, let’s return to the computer itself. Most computers in use today uses block devices to store data. Block devices are hardware devices that uses the random fixed-size chunks of data, called blocks. The most famous and common block device is a hard disk. The other type of device is a character device, accessed as a stream of sequential data, one byte after another. Well known examples are serial ports and keyboards. Note: you can use a serial port to transfer or in some cases even store data while the keyboard is used to input data.
So in cases where the hardware device is accessed as a stream of data, it is implemented as a character device. While devices accessed randomly are block devices. In the case of flash storage device, the computer sees the device as block one. But, its individual cells, which will be used to store data, are in fact different. A block device layer which emulates a disk drive general-purpose file system can be used on a flash-based storage device. This approach is ‘OK’ from the computer’s point of view. But, there are several reasons why this is not such a good solution for flash devices.
Flash memory blocks have to be explicitly erased before they can be written to. The time taken to erase blocks can be significant. Thus, in most cases, the erasure of unused blocks is applied while the device is idle. While flash memory imposes no seek latency and most of the file systems are designed for hard disks and other mechanical based storage devices, this solution can not be successfully applied to a flash device. Another problem comes from the design of flash memory, which tends to wear out when a single block is repeatedly overwritten (this is not the case with hard disk drives). Flash File Systems are designed to spread out the writes evenly.
Limitations of bare NAND flash memory devices are: erasure on the block level, finite number of erase-write cycles (usually up to 10000 cycles) and bit flip possibilities. These limitations lead to the creation of file systems primarily designed for flash storage devices. While the origin of these file systems are in Linux platforms most of the present day flash devices have an integated special layer called the Flash Translation Layer or FTL. The purpose of this layer is to emulate computer I/O requests and the flash memory itself. They are implemented inside a flash memory controller, usually mounted between the connection cable and memory chip. In fact this should be observed as physical hardware dealing with a flash file system. So, we return to where we started, the flash file system. These days flash developers working on new FTL can use file systems which are already available through the set of libraries in their IDE or they can create a variation of the same thing.
Flash file systems are mostly found in embedded devices such as mobile phones. File systems such as: JFFS, YAFFS, LogFS, UBIFS and their versions listed below are primarily designed for Linux platforms. Another good example is F2FS.
Journaling Flash File System
Journaling Flash File System (JFFS) designed by David Woodhouse along with it’s Version 2 has been integrated in Linux kernel since 2001. It is commonly used for low volume flash devices and its practical usage in the latest MLC and TLC memory chips has been disputed. While compression is indeed supported very few devices or developers actually uses this file system any longer.
Yet Another Flash File System
Yet another Flash File System (YAFFS), designed by Charles Manning and its version 2 was also integrated into Linux kernel from the early 2000s. YAFFS was the very first file system designed specifically for NAND memory. Since 2005 YAFFS and it’s Version 2 has supported 2KB large NAND pages as well as compression support.
Log Flash File System
Log Flash File System (LogFS) designed by Jörn Engel along with it’s version 2 has been integrated in Linux kernel since 2005. Although still under development, especially for large devices, LogFS can also be compressed in ELC2009. This file system is famous for a very fast mounting time with compressed metadata while user data is left uncompressed.
Unsorted Block Image File System
Unsorted Block Image File System (UBIFS) designed by Artem Bityutskiy and Adrian Hunter was also integrated into LInux kernel in 2.6.27 in October of 2008. This file system works mainly on top of the UBI volumes. UBI, as stated before stands, for “Unsorted Block Images”. It is a volume management system for raw flash devices which manages multiple logical volumes on a single physical flash device and spreads the I/O load (such as wear-leveling) across whole flash chip. UBI may be compared to the Logical Volume Manager (LVM). Whereas LVM maps logical sectors to physical sectors, UBI maps logical erase blocks to physical eraseblocks. But, besides the mapping, UBI implements global wear-leveling and transparent I/O errors handling. UBIFS supports compressing.
Flash-Friendly File System
Flash-Friendly File System (F2FS) designed mainly by Jaegeuk Kim was added to the Linux kernel 3.8. in 2013 and initially developed by Samsung Electronics. Instead of being designed to communicate directly to raw flash devices, F2FS is designed to be used on flash-based storage devices that already include a flash translation layer as number of these continues to rise.
Watch Video
We listed these file systems since Linux operating system can mount almost anything. Some experienced Linux enthusiasts we’ve hung out with have joked many times saying,” give me a brick and I will find a way to attach it to the computer running Linux”. Funny statement? Sure! But, there is much truth in irony.
Check back for our next article to read more about the FTL, or Flash Translation Layer.
