HowYaffsWorks

How YAFFS Works

Charles Manning

2007-2010

Table of Contents

1 Purpose...................................................................................................................................................2

2 What Is YAFFS?....................................................................................................................................2

3 Design and coding strategies..................................................................................................................2

4 Terminology: YAFFS vs YAFFS1 vs YAFFS2....................................................................................3

5 Objects...................................................................................................................................................3

11 Bad block handling NAND error handling........................................................................................11

12 RAM structures..................................................................................................................................12

12.1.yaffs_Object................................................................................................................................13

12.2.ObjectId look-up..........................................................................................................................13

12.3.Directory structure.......................................................................................................................14

12.4.Hard links....................................................................................................................................15

12.5.Symbolic link and special object.................................................................................................16

12.6.File object....................................................................................................................................16

12.6.1 Tnode tree...........................................................................................................................16

13 How various mechanisms work.........................................................................................................17

13.3.Scanning......................................................................................................................................22

13.3.1 YAFFS1 Scanning..............................................................................................................22

13.3.2 YAFFS2 Scanning..............................................................................................................22

13.4.Checkpoint...................................................................................................................................23

13.5.Extended Tags and Packed Tags.................................................................................................24

13.6.Inband tags..................................................................................................................................24

13.7.Soft Deletion................................................................................................................................25

Page 1/25

1 Purpose

The purpose of this document is to give a reasonable explanation of most of the core mechanisms that make yaffs work. As

2 What Is YAFFS?

YAFFS stands for Yet Another Flash File System, a term coined by Charles Manning in 2001 when suggesting that the

already cluttered flash file system space could do with yet another offering – this time a flash file system designed from the

The first release of YAFFS was developed during the end of 2001 and the beginning of 2002. By mid-2002, YAFFS was

being trialled in various products. In May 2002, YAFFS was announced and a few more projects started playing with it. In

June, porting to other OSs started. In September 2002, YAFFS was announced on linuxdevices.com which started a far

wider uptake of YAFFS.

YAFFS1, the original version of YAFFS, supported 512-byte page NAND devices with a SmartMedia-like memory layout.

YAFFS2 is a follow-up to YAFFS1 extending YAFFS1 to support larger and different devices with different constraints.

YAFFSis highly portable and has been used in many different products and applications as varied as sewing machines,

point of sale, phones and aerospace. YAFFS has been used with multiple different operating systems. Native support is

available for Linux, WindowsCE and eCOS while yaffs Direct Interface provides a layer that can be used in other

portability include:

● No OS-specific features used in main code body.

● No compiler-specific features used in the main code body.

● Abstract types and functions used to allow Unicode or ASCII operation.

Page 2/25

Simplicity is another key goal. Complexity is limited to those situations that provide significant improvements to

performance or utility. Simplicity improves robustness and the ease of integration and development. Primary strategies that

improve simplicity are:

● Single threaded model. YAFFS is locked on a per-partition basis at a high level. This is simpler than tracking

lower-level locking. Yaffs Direct Interface uses a single lock for all partitions.

● Log structure makes for a simpler garbage collector and allocation methodology.

base supports the yaffs1 mode of operation through a backward compatibility mode.

Unless explicitly mentioned, this text refers to the yaffs2 code-base.

This text uses three terms YAFFS, YAFFS1 and YAFFS2 depending on various modes of operation.

•YAFFS1 is a simpler mode of operation that uses deletion markers to track state.

•YAFFS2 is a more complex mode of operating that was developed to support larger flash types that cannot used deletion

markers.

•YAFFS means operations common to both.

YAFFS1 originally only worked with 512-byte page devices but has been extended to support larger flash pages such as

Intel M18 flash with 1k pages.

YAFFS2 was originally designed for 1k or larger page sizes but can be used with smaller pages by using in-band tags.

● Directories

● Hard-links

● Symbolic links

Page 3/25

● Special objects (pipes, devices etc).

All objects are identified by a unique integer objectId.

In the standard POSIX model, as used by Linux, there are inodes and directory entries (dentries).

An inode may be a regular file, directory, or special file.

Directory entries provide the naming mechanism that is used to locate inodes.

Under POSIX, each inode may have zero, one or many dentries:

● One dentry per inode is commonly understood.

The memory in NAND flash is arranged in pages. A page is the unit of allocation and programming. In YAFFS, the unit of

allocation is the chunk. Typically a chunk will be the same as a NAND page, but there is flexibility to use chunks which

map to multiple pages (eg. A system may have two NAND chips in parallel requiring 2x512 = 1024 byte chunks) . This

distinction gives a lot of flexibility in how the system can be configured. In this text the term page and chunk are

synonymous unless stated otherwise.

Many, typically 32 to 128 but as many as a few hundred, chunks form a block. A block is the unit of erasure.

NAND flash may be shipped with bad blocks and further blocks may go bad during the operation of the device. Thus,

YAFFS is aware of bad blocks and needs to be able to detect and mark bad blocks.

NAND flash also typically requires the use of some sort of error detection and correction code (ECC). YAFFS can either

use existing ECC logic or provide its own.

● Data chunk: A chunk holding regular data file contents.

● Object Header: A descriptor for an object (directory,regular data file, hard link, soft link, special descriptor,...).

This holds details such as the identifier for the parent directory, object name, etc.

Page 4/25

Each chunk has tags associated with it. The tags comprise the following important fields (others being ignored for now):

● ObjectId: Identifies which object the chunk belongs to.

● ChunkId: Identifies where in the file this chunk belongs. A chunkId of zero signifies that this chunk contains an

objectHeader. ChunkId==1 signifies the first chunk in the file (ie. At file offset 0), chunkId==2 is the next chunk

and so on.

● Deletion Marker: (YAFFS1 only) Shows that this chunk is no longer in use.

● Byte Count: Number of bytes of data if this is a data chunk.

Next we write a few chunks of data to the file.

Next we close the file. This writers a new object header for the file. Notice how the previous object header is deleted.

Page 5/25