J
Jarret W. Buse
Guest
Journaling Flash File System version 2 (JFFS2)
The Journaling Flash File System version 2 (JFFS2) was created by Red Hat from JFFS started by Axis Communications. JFFS2 was introduced with Linux kernel 2.4.10 on September 2001. As its name implies, it is for flash drives, but not the standard USB thumb drives. These types of flash drives are the Memory Technology Devices (MTD). In this case, MTDs can hold boot information and even an OS.
JFFS2 has a maximum volume size of 128 MB.
JFFS2 has a log based structure which works like a Journal. Log based structures perform sequential writes from beginning to end to a log file, or a buffer. Once the space is filled, it performs similar to circular logging. If a file is updated, the old file remains and a new one is placed at the end of the log. When needed, the older file can be overwritten. Files not updated are kept. This reduces overhead by not requiring continual erases with every file modified. Performance issues can occur when the media becomes full. What can occur is that writes can be performed in batches instead of a few writes here and there when the log gets full. JFFS2 creates older versions of files and can be used in similar ways as Snapshots. When a crash occurs, files can be reconstructed from the log.
Folders and files written to a JFFS2 flash drive are logged in sections called nodes. There are two types of nodes:
When a file is renamed, a new dirent node is created with the new file name and the inode number. This is similar to a hard link being created. Then, the inode number for the original dirent entry is changed to zero. Changing the number to a zero unlinked the older entry.
JFFS2 has the following features:
The Journaling Flash File System version 2 (JFFS2) was created by Red Hat from JFFS started by Axis Communications. JFFS2 was introduced with Linux kernel 2.4.10 on September 2001. As its name implies, it is for flash drives, but not the standard USB thumb drives. These types of flash drives are the Memory Technology Devices (MTD). In this case, MTDs can hold boot information and even an OS.
JFFS2 has a maximum volume size of 128 MB.
JFFS2 has a log based structure which works like a Journal. Log based structures perform sequential writes from beginning to end to a log file, or a buffer. Once the space is filled, it performs similar to circular logging. If a file is updated, the old file remains and a new one is placed at the end of the log. When needed, the older file can be overwritten. Files not updated are kept. This reduces overhead by not requiring continual erases with every file modified. Performance issues can occur when the media becomes full. What can occur is that writes can be performed in batches instead of a few writes here and there when the log gets full. JFFS2 creates older versions of files and can be used in similar ways as Snapshots. When a crash occurs, files can be reconstructed from the log.
Folders and files written to a JFFS2 flash drive are logged in sections called nodes. There are two types of nodes:
- inode – metadata with optional data
- Directory Entry (dirent) node – directory name with inode number. When the file is the same but in two different locations, the inode number is the same (hard link).
When a file is renamed, a new dirent node is created with the new file name and the inode number. This is similar to a hard link being created. Then, the inode number for the original dirent entry is changed to zero. Changing the number to a zero unlinked the older entry.
JFFS2 has the following features:
- Better performance than JFFS because of the garbage collecting algorithm used in the circular logging. The log file used in JFFS can treat the whole flash drive as one circular log. JFFS2 uses a garbage collecting algorithm to find unneeded information and deletes it. Once space is freed, then more data can be written and performance remains good until the space starts to fill. The process is that JFFS2 blocks are filled from one end to the other. Blocks which are empty are considered free. When a node in a block is obsolete, the block is then considered dirty. Blocks with valid nodes are clean. The garbage collecting algorithm finds dirty blocks and cleans them to be free blocks.
- Hard links used to store the same file with multiple names or paths. JFFS2 uses hard links. Hard links are used to store a file once on the drive and have multiple pointers to it. For example, if File1 exists in DirectoryA and we then copy it to DirectoryB, File1 exists one time on the drive but is in the file list twice. The addressing table points both path and filenames to the same address. Since the file only exists once, space is saved. Once a file is modified, it is then written and one pointer changed.
- Use on NAND devices. NAND (Not AND) devices uses floating gate transistors connected in a NAND gate. Each NAND bit has a theoretical number of writes, of 100,000 times, before a failure. NAND devices groups blocks as 128 KB. When erased, the bits are all ‘1’. NAND devices can cause a Read Disturb which occurs when one bit is being written, that it disturbs the charge in an adjacent bit.
- Compression of files to save space. JFFS2 supports the use of file compression to save storage space. JFFS2 uses four different types of compression:
- rubin - The rubin compression algorithm is a fast compressor, but does not compress as small as zlib.
- Lempel–Ziv–Oberhumer (LZO) - The Lempel–Ziv–Oberhumer (LZO) has comparable compression to zlib, but decompresses faster.
- rtime - The rtime compression algorithm can usually compress an already compressed file a few more bytes.
- zlib - The zlib compression uses only the DEFLATE algorithm. The method works well for a variety of data types.
