YAFFS

Last updated

YAFFS
Developer(s) Charles Manning
Full nameYet Another Flash File System
Other
Supported
operating systems 		Android, Firefox OS, Linux, Windows CE, pSOS, RTEMS, eCos, ThreadX, LCOS

YAFFS (Yet Another Flash File System) is a file system designed and written by Charles Manning for the company Aleph One.

Contents

YAFFS1 was the first version of this file system and was designed for the then-current NAND chips with 512 byte page size (+ 16 byte spare (OOB; Out-Of-Band) area). Work started in 2002, and it was first released later that year. The initial work was sponsored by Toby Churchill Ltd, and Brightstar Engineering.

These older chips also generally allow 2 or 3 write cycles per page. [1] YAFFS takes advantage of this: dirty pages are marked by writing to a specific spare area byte. Newer NAND flash chips have larger pages, first 2K pages (+ 64 bytes OOB), later 4K, with stricter write requirements. Each page within an erase block (128 kilobytes) must be written to in sequential order, and each page must be written only once.[ citation needed ]

Designing a storage system that enforces a "write once rule" ("write once property") has several advantages. [2]

YAFFS2 was designed to accommodate these newer chips. It was based on the YAFFS1 source code, with the major difference being that internal structures are not fixed to assume 512 byte sizing, and a block sequence number is placed on each written page. In this way older pages can be logically overwritten without violating the "write once" rule. It was released in late 2003.

YAFFS is a robust log-structured file system that holds data integrity as a high priority. A secondary YAFFS goal is high performance. YAFFS will typically outperform most alternatives. [3] It is also designed to be portable and has been used on Linux, WinCE, pSOS, RTEMS, eCos, ThreadX, and various special-purpose OSes. A variant 'YAFFS/Direct' is used in situations where there is no OS, embedded OSes or bootloaders: it has the same core filesystem but simpler interfacing to both the higher and lower level code and the NAND flash hardware.

The YAFFS codebase is licensed both under the GPL and under per-product licenses available from Aleph One.

YAFFS is locked on a per-partition basis at a high level, allowing only one thread to write at any given time. [4]

YAFFS1

There is no special procedure to initialize a YAFFS filesystem beyond simply erasing the flash memory. When a bad block is encountered, YAFFS follows the smart media scheme of marking the fifth byte of the block's spare area. Blocks marked as such remain unallocated from then on.[ clarification needed ]

To write file data, YAFFS initially writes a whole page (chunk in YAFFS terminology) that describes the file metadata, such as timestamps, name, path, etc. The new file is assigned a unique object ID number; every data chunk within the file will contain this unique object ID within the spare area. YAFFS maintains a tree structure in RAM of the physical location of these chunks. When a chunk is no longer valid (the file is deleted, or parts of the file are overwritten), YAFFS marks a particular byte in the spare area of the chunk as 'dirty'. When an entire block (32 pages) is marked as dirty, YAFFS can erase the block and reclaim the space. When the filesystem's free space is low, YAFFS consolidates a group of good pages onto a new block. YAFFS then reclaims the space used by dirty pages within each of the original blocks.

When a YAFFS system mounts a NAND flash device, it must visit each block to check for valid data by scanning its spare area. With this information it then reconstitutes the memory-resident tree data structure.

YAFFS2

YAFFS2 is similar in concept to YAFFS1, and shares much of the same code; the YAFFS2 code base supports YAFFS1 data formats through backward compatibility. The main difference is that YAFFS2 needs to jump through significant hoops to meet the "write once" requirement of modern NAND flash. [5]

YAFFS2 marks every newly written block with a sequence number that is monotonically increasing. The sequence of the chunks can be inferred from the block sequence number and the chunk offset within the block. Thereby when YAFFS2 scans the flash and detects multiple chunks that have identical ObjectIDs and ChunkNumbers, it can choose which to use by taking the greatest sequence number. For efficiency reasons YAFFS2 also introduces the concept of shrink headers. For example, when a file is resized to a smaller size, YAFFS1 will mark all of the affected chunks as dirty – YAFFS2 cannot do this due to the "write once" rule. YAFFS2 instead writes a "shrink header", which indicates that a certain number of pages before that point are invalid. This lets YAFFS2 reconstruct the final state of the filesystem when the system reboots.

YAFFS2 uses a more abstract definition of the NAND flash allowing it to be used with a wider variety of flash parts with different geometries, bad block handling rules etc.

YAFFS2 later added support for checkpointing, which bypasses normal mount scanning, allowing very fast mount times. Performance will vary, but mount times of 3 seconds for 2 GB have been reported.[ citation needed ]

See also

Related Research Articles

ext2, or second extended file system, is a file system for the Linux kernel. It was initially designed by French software developer Rémy Card as a replacement for the extended file system (ext). Having been designed according to the same principles as the Berkeley Fast File System from BSD, it was the first commercial-grade filesystem for Linux.

ext3, or third extended filesystem, is a journaled file system that is commonly used with the Linux kernel. It used to be the default file system for many popular Linux distributions but generally has been supplanted by its successor version ext4. The main advantage of ext3 over its predecessor, ext2, is journaling, which improves reliability and eliminates the need to check the file system after an improper, a.k.a. unclean, shutdown.

<span class="mw-page-title-main">Flash memory</span> Electronic non-volatile computer storage device

Flash memory is an electronic non-volatile computer memory storage medium that can be electrically erased and reprogrammed. The two main types of flash memory, NOR flash and NAND flash, are named for the NOR and NAND logic gates. Both use the same cell design, consisting of floating gate MOSFETs. They differ at the circuit level depending on whether the state of the bit line or word lines is pulled high or low: in NAND flash, the relationship between the bit line and the word lines resembles a NAND gate; in NOR flash, it resembles a NOR gate.

Disk formatting is the process of preparing a data storage device such as a hard disk drive, solid-state drive, floppy disk, memory card or USB flash drive for initial use. In some cases, the formatting operation may also create one or more new file systems. The first part of the formatting process that performs basic medium preparation is often referred to as "low-level formatting". Partitioning is the common term for the second part of the process, dividing the device into several sub-devices and, in some cases, writing information to the device allowing an operating system to be booted from it. The third part of the process, usually termed "high-level formatting" most often refers to the process of generating a new file system. In some operating systems all or parts of these three processes can be combined or repeated at different levels and the term "format" is understood to mean an operation in which a new disk medium is fully prepared to store files. Some formatting utilities allow distinguishing between a quick format, which does not erase all existing data and a long option that does erase all existing data.

Wear leveling is a technique for prolonging the service life of some kinds of erasable computer storage media, such as flash memory, which is used in solid-state drives (SSDs) and USB flash drives, and phase-change memory. There are several wear leveling mechanisms that provide varying levels of longevity enhancement in such memory systems.

Journalling Flash File System version 2 or JFFS2 is a log-structured file system for use with flash memory devices. It is the successor to JFFS. JFFS2 has been included into the Linux kernel since September 23, 2001, when it was merged into the Linux kernel mainline as part of the kernel version 2.4.10 release. JFFS2 is also available for a few bootloaders, like Das U-Boot, Open Firmware, the eCos RTOS, the RTEMS RTOS, and the RedBoot. Most prominent usage of the JFFS2 comes from OpenWrt.

The Journaling Flash File System is a log-structured file system for use on NOR flash memory devices on the Linux operating system. It has been superseded by JFFS2.

In computer science, execute in place (XIP) is a method of executing programs directly from long-term storage rather than copying it into RAM. It is an extension of using shared memory to reduce the total amount of memory required.

The following tables compare general and technical information for a number of file systems.

badblocks is a Linux utility to check for bad sectors on a disk drive. It can create a text file with list of these sectors that can be used with other programs, like mkfs, so that they are not used in the future and thus do not cause corruption of data. It is part of the e2fsprogs project, and a port is available for BSD operating systems.

Btrfs is a computer storage format that combines a file system based on the copy-on-write (COW) principle with a logical volume manager, developed together. It was created by Chris Mason in 2007 for use in Linux, and since November 2013, the file system's on-disk format has been declared stable in the Linux kernel.

UBIFS is a flash file system for unmanaged flash memory devices. UBIFS works on top of an UBI layer, which is itself on top of a memory technology device (MTD) layer. The file system is developed by Nokia engineers with help of the University of Szeged, Hungary. Development began in earnest in 2007, with the first stable release made to Linux kernel 2.6.27 in October 2008.

A flash file system is a file system designed for storing files on flash memory–based storage devices. While flash file systems are closely related to file systems in general, they are optimized for the nature and characteristics of flash memory, and for use in particular operating systems.

shred is a command on Unix-like operating systems that can be used to securely delete files and devices so that it is extremely difficult to recover them, even with specialized hardware and technology; assuming recovery is possible at all, which is not always the case. It is a part of GNU Core Utilities. Being based on the Gutmann method paper, it suffers from the same criticisms and possible shortcomings.

A trim command allows an operating system to inform a solid-state drive (SSD) which blocks of data are no longer considered to be "in use" and therefore can be erased internally.

<span class="mw-page-title-main">Write amplification</span> Phenomenon associated with solid state storage

Write amplification (WA) is an undesirable phenomenon associated with flash memory and solid-state drives (SSDs) where the actual amount of information physically written to the storage media is a multiple of the logical amount intended to be written.

<span class="mw-page-title-main">Flash memory controller</span> Integrated circuit that interfaces flash memory to a host like a PC

A flash memory controller manages data stored on flash memory and communicates with a computer or electronic device. Flash memory controllers can be designed for operating in low duty-cycle environments like memory cards, or other similar media for use in PDAs, mobile phones, etc. USB flash drives use flash memory controllers designed to communicate with personal computers through the USB port at a low duty-cycle. Flash controllers can also be designed for higher duty-cycle environments like solid-state drives (SSD) used as data storage for laptop computer systems up to mission-critical enterprise storage arrays.

F2FS is a flash file system initially developed by Samsung Electronics for the Linux kernel.

References

  1. ↑ Erasing a flash erase block sets all of its bits to 1s, and writing a write block (smaller than an erase block, but possibly bigger than a filesystem block) sets selected bits to 0s. One or two further writes to the block could be sustained if the bits being written to 0 were previously 1s in the write block. Writing a 0 to a bit which was already 0 risked making the 0 "stick", i.e. multiple erases could be needed to return the bit to a 1.[ citation needed ] Needless to say, this multiple-write practice was not generally tested and guaranteed by flash vendors, and cannot work at all on non-SLC flash technologies.
  2. ↑ Jack B. Dennis; Guang R. Gao; and Vivek Sarkar. "Collaborative Research: Programming Models and Storage System for High Performance Computation with Many-Core Processors". p. 4
  3. ↑ "Flash filesystem benchmarks Linux 3.1".
  4. ↑ "How Yaffs works | Yaffs – A Flash File System for embedded use". yaffs.net. Retrieved 2024-03-18.
  5. ↑ "YAFFS 2 Specification and Development Notes".
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.