A Flash File System to Support Fast Mounting for NAND Flash ...
A Flash File System to Support Fast Mounting
for NAND Flash Memory Based
Song-Hwa Park1, Tae-Hoon Lee1 , and Ki-Dong Chung2
Dept. of Computer Science, Pusan National University,
Kumjeong-Ku, Busan 609-735, Korea
Abstract. In embedded systems, NAND ﬂash memory is typically used
as a storage medium because of its non-volatility, fast access time and
solid-state shock resistance. However, it suﬀers from out-place-update,
limited erase cycles and page based read/write operations. Flash ﬁle
systems such as JFFS2 and YAFFS, allocate memory spaces using LFS
(Log-structured File System) to solve these problems. Because of this,
many pieces of a ﬁle are scattered through out ﬂash memory. Therefore,
these ﬁle systems should scan entire ﬂash memory to construct the data
structures during the mounting. This means that it takes a long time
to mount such ﬁle systems on a large chip. In this paper, we design and
propose a new ﬂash memory ﬁle system which targets mobile devices that
require fast mounting. We experimented on the ﬁle system performance
and the results show that we improve the mounting time by 64%–76%
as ﬂash usage compared to YAFFS.
Embedded computing systems such as mp3 player, digital camera and RFID
reader should be able to provide an instant start-up time . In these systems,
ﬂash memory is widely used as storage system because of its beneﬁts. It is non-
volatile, meaning that it retains data even after power is turned oﬀ and consumes
relatively little power. In addition, ﬂash memory oﬀers fast access times and
solid-state shock resistance. These characteristics explain the popularity of ﬂash
memory for embedded systems.
There are two major type of ﬂash memory according to the gate type and
structure of the memory cell: NOR ﬂash and NAND ﬂash. For NOR ﬂash mem-
ory, the page size is typically 1 byte, meaning that each byte can be read and
written individually. For NAND ﬂash memory, on the other hand, the page size
This work was supported by the Regional Research Centers Program (Research
Center for Logistics Information Technology), granted by the Korean Ministry of
Education & Human Resources Development.
S. Vassiliadis et al. (Eds.): SAMOS 2006, LNCS 4017, pp. 415–424, 2006.
c Springer-Verlag Berlin Heidelberg 2006
416 S.-H. Park, T.-H. Lee, and K.-D. Chung
is typically 512 bytes, so it oﬀers higher read/write performance than NOR ﬂash
memory. As a result, it is widely used as the secondary storage systems .
Despite the advantages of NAND ﬂash memory, it has several hardware char-
acteristics that make straightforward replacement of existing storage media dif-
ﬁcult. Firstly, it suﬀers from inability that does not provide the update-in-place.
In ordinary writing, it can transit from one state (called initial state) to an-
other, but it can’t make the reverse transition. As a result, block erase operation
is required for rewriting the contents of a block. Secondly, it can not be read or
programmed smaller than a page (e.g. 512B, 2KB). Lastly, blocks have limited
endurance due to wear out on the insulating oxide layer around the charge stor-
age mechanism used to store data. Therefore the erase operation must be done
evenly to all blocks to avoid wearing out speciﬁc blocks which would aﬀect the
usefulness of the entire ﬂash memory. This is usually named as wear leveling or
cycle leveling .
As the conventional ﬁle systems cannot be applied directly to ﬂash memories
due to above mentioned limitations, new ﬂash ﬁle systems such as JFFS2  and
YAFFS  were developed. JFFS2 is a journaling ﬁle systems based on ﬂash mem-
ory that keep metadata to avoid errors and corruption. Files are broken into several
smaller nodes, which contain the actual data. When update operation occurs, a new
node is created and the updated data is written to the node. Therefore, JFFS2 must
scan the entire ﬂash memory space at mounting time to collect the scattered data.
Then the collected data are reorganized in RAM. It takes a long time and memory
consumption is enormous. YAFFS is the ﬁrst ﬁle system that is designed speciﬁ-
cally for NAND ﬂash memory and outperforms JFFS2 with respect to mount time
and amount of memory consumption. However, it also has a long mounting time
problem because it scans the spare areas of every block to check validation of data.
In cases of JFFS2 and YAFFS, the ﬂash mount time heav-ily depends on the ﬂash
capacity and stored data size.
Since ﬂash chip capacity is increasing every year, the ﬂash mounting time will
soon become the most dominant reason of the delay of system start-up time
. Our goal is to design and implement a fast NAND ﬂash ﬁle system. To
support fast mounting, we keep the location of the required data such as block
information, metadata during the mounting.
This paper is organized as follows. In Section 2, we describe JFFS and YAFFS,
the ﬂash ﬁle systems, respectively. In Section 3, we present our proposed ﬁle
system to support fast mounting. The evaluation results are presented in Section
4, and the con-clusion is shown in Section 5.
2 NAND Flash File Systems
In this section, we introduce the ﬂash ﬁle system, JFFS2 and YAFFS.
JFFS was originally developed for the 2.0 kernel by Axix Communications in
Sweden. It is a journaling ﬁle system designed for small NOR (≤ 32MB) ﬂash
A Flash File System to Support Fast Mounting 417
memory. David Woodhouse and others improved JFFS and developed JFFS2
which addresses the issues of JFFS by providing compression, automatic leveling
and NAND ﬂash mem-ory support .
JFFS2 consists of simply a list of nodes and log entries. Each node contains
actual data to be inserted into ﬁles or delete instructions and a log entry contains
information about write operations on ﬁle. Nodes are written to ﬂash sequentially
starting at the ﬁrst block. When update operation occurs, the updated data
is written to other place since JFFS2 is based on LFS (Log-structured File
System) to solve the out-of-place problem . This makes the related nodes and
log entries on the same ﬁle scattered throughout the ﬂash memory. In order to
collect the scattered data, JFFS2 scans all nodes and log entries to construct ﬁle
system at mounting time. Also it checks the consistency and executes a garbage
collection thread during the mounting. The gar-bage collection thread copies
valid nodes in one block to another block, then erases blocks to get free space.
Therefore, JFFS takes a long mounting time and consumes large amount of main
Even though JFFS2 solved and improved the problems of JFFS, it has still
some problems when applied to the NAND ﬂash memory. Firstly, the arbitrary
size of jour-naling nodes causes a fragmentation of pages on NAND ﬂash memory.
Secondly, JFFS2 has faced the serious problems such as slow mounting and
wasteful memory consump-tion as NAND ﬂash chips become larger. To overcome
these problems, the JFFS3  draft was issued and developed.
2.2 YAFFS 
YAFFS (Yet Another Flash Filing System) is the ﬁrst ﬁle system designed specif-
ically for NAND ﬂash memory. It was designed and developed by Charles Man-
ning of the company Aleph One. Instead of using a kind of translation layer such
as FTL on ﬂash devices to emulate a normal hard drive, it places the ﬁle system
directly on the ﬂash chips. Fig. 1 shows the organization of YAFFS. It works
on a small NAND ﬂash memory which consists of several blocks. Generally, a
small NAND ﬂash memory is composed of 32 pages and each page has spare
area which contains the additional information on corresponding page.
Fig. 1. Flash memory structure of YAFFS
418 S.-H. Park, T.-H. Lee, and K.-D. Chung
In YAFFS, data is stored on NAND ﬂash in chunks. Each chunk is the same
size as a page and has a unique id (referred as chunkID). A chunk can hold either
an object header or ﬁle data. If chunkID of a chunk is zero, the chunk holds an
object header which describes a directory, ﬁle, symbolic link or hard link. Other-
wise, the chunks holds ﬁle data and the value of chunkID indicates the position
of the chunk in the ﬁle . The spare area contains the information about the
corresponding chunk such as chunkID, serialNumber, byteCount, objectID and
ECC and others. When a chunk is no longer valid, YAFFS marks a particular
byte in the spare area of the chunk as dirty. When entire pages of a block are
marked as dirty, YAFFS erases the block and re-claim the space. If free space on
the device is low, YAFFS chooses a block that has some number of dirty pages
and valid pages. In this case, the valid pages are moved to a new block accord-
ing to garbage collection and the old pages are marked as dirty. YAFFS marks
every newly written chunk with a serial number that is monotonically increasing.
Thereby when YAFFS scans the ﬂash, it may detect multiple data chunks of one
ﬁle that have identical ChunkID. It can choose the latest chunk by taking the
greatest serial number. However, the data chunks are scattered throughout ﬂash
mem-ory, YAFFS should scan the entire ﬂash memory at mounting time. This
means that the mounting time of YAFFS heavily depends on the ﬂash capacity
and the stored data size the same as JFFS2.
3 A NAND Flash File System to Support Fast Mounting
In this section, we describe the NAND ﬂash ﬁle system architecture which sup-
ports fast mounting.
3.1 On-Flash Data Structures
In this paper, we aim to provide fast mounting without regard to the ﬂash
memory capacity and amount of stored data. To satisfy this requirement, we
propose a ﬁle system architecture in ﬂash memory as is shown in Fig 2. In case
of JFFS2 and YAFFS, the related data are spread all around ﬂash memory. This
scheme causes long mounting time. Therefore, keeping the location of the related
data is the key to support fast mounting.
In the proposed architecture, the ﬂash memory is managed as separated two
areas, Location Information Area (referred as LIA) and General Area (referred
as GA). Es-pecially, LIA maintains the latest location information. It occupies
the several groups of blocks and ﬁrstly read during the mounting. GA is the
remaining area except LIA in ﬂash memory. In this area, all sub-areas such as
metadata, data and block information are stored. Let us show the characteristics
of each sub-area one by one.
Location Information Area. LIA keeps the latest location information where
the metadata and block status are written. LIA is set to a ﬁxed size and used
in a round-robin manner. Loc Info, the data structure for location information,
is described in the left side of Fig. 2. It is a page-size data structure due to the
A Flash File System to Support Fast Mounting 419
Fig. 2. The proposed ﬂash ﬁle system architecture in ﬂash memory
limitation of NAND ﬂash memory I/O unit. Loc Info consists of block info and
meta data ﬁelds. Block info ﬁelds point to the location where the latest block
information are written. Array of meta data ﬁeld stores the latest addresses of
the metadata sub-area where the metadata are stored. The number of index in
the array limits the maximum number of ﬁles in the ﬁle system. In Fig. 2, the
maximum number of ﬁles is 16,205.
General Area. GA includes all sub-areas such as metadata, ﬁle data and
block info. These sub-areas except data block are managed based on segment
unit. Let us show the characteristics of each sub-area. First, metadata area con-
sists of a number of independent segments which composed of several blocks.
We store all metadata for objects such as ﬁles, directories, hard links and sym-
bolic links in this area. Fig. 3 shows the Meta Data structure of the proposed
Fig. 3. An example of management of a ﬁle using Meta Data
420 S.-H. Park, T.-H. Lee, and K.-D. Chung
Fig. 4. Block Info data structure containing status of all blocks in ﬂash
ﬁle system. Unlike the conventional ﬂash ﬁle system such as JFFS2 and YAFFS,
the proposed ﬁle system contains ﬁle locations in metadata. Since all Meta Data
structures are belonged to metadata sub-area, we can construct the data struc-
tures in RAM by only scanning the metadata sub-area during the mounting.
Second, block info area stores the Block Info data structures that contain the
newly updated status of all blocks in ﬂash memory. For each block, Block Info
keeps the information of the number of pages in use, block status, block type and
etc. as shown in Fig. 4. We make use of this information to determine policies
such as new block allocation and garbage collection. When unmounting the ﬁle
system, the latest Block Info structures are written to ﬂash memory.
3.2 In-Memory Data Structures
A procedure which mounts the ﬁle system includes constructing of block status
and creating the data structure for object in RAM. A directory, ﬁle, hard link
and symbolic link are abstracted to objects. Object structures are created for
run-time support of operations on opened ﬁle and are managed by a list. For
a ﬁle, Fnodes forms a tree structure that speeds up the search for data chunks
in a ﬁle. The memory consumption of the proposed ﬁle system is similar to
that of YAFFS since it also maintains the data structure for block information,
metadata and data locations in RAM.
Block Status data structure. The block info area stores the Block Info data
structures that contain the status of all blocks in ﬂash memory. The Block Status
data structures are created in RAM using the Block Info data. These contain
the information of corresponding block information and are managed by using
an array. The index of an array denotes the corresponding block number. The
Block Status in RAM reﬂects the change on block status in ﬂash memory. The
Fig. 5 shows an example of Block Status update. As an application performs
A Flash File System to Support Fast Mounting 421
Fig. 5. An example of Block Status update in RAM
write operation, we allocate the space using the Block Status information in
RAM. The 20th block status is changed as the pages in the block are allocated
for write operation. When unmounting the ﬁle system, the updated Block Status
information is stored in block info area.
Object data structure. An object can be a directory, ﬁle, hard link or sym-
bolic link. During the mounting, the Object structures are created in RAM by
loading Meta Datas in metadata area. The relationship between these two struc-
tures is illustrated in Fig. 6. An Object knows about its corresponding metadata
Fig. 6. Object management in RAM
422 S.-H. Park, T.-H. Lee, and K.-D. Chung
Fig. 7. Fnode data structure
location in ﬂash memory. Modiﬁcations to the directory, ﬁle, hard link or sym-
bolic link are reﬂected in the Object as they occur.
Fnode data structure. The ﬁle locations are maintained by a tree structure
as described in Fig. 7. For a ﬁle, the Fnode data structures are created in RAM
for managing its data location. The Fnode structures form a tree structure that
speeds up the search for data chunks in a ﬁle. Depending on where it is in the
tree, each Fnode holds the dif-ferent information. If it is at the lowest level,
then it points to the data location. Otherwise, it points to lower-level Fnodes.
When the ﬁle is created, it is assigned only one low-level Fnode. When the ﬁle
expands past what a single Fnode can hold, then it is assigned a second Fnode
and an internal node is added to point to the two Fnodes. As the ﬁle grows,
more low-level Fnodes and high level Fnodes are added.
4 Experimental Results
In this section, we evaluate the performance of the proposed ﬁle system.
4.1 Experiment Environment
We implemented our proposed ﬁle system and experimented using an embedded
board. We used PXA255-Pro III board made by Huins. Fig. 8 summarizes the
PXA255-Pro III board speciﬁcation. We used 64 MB Samsung NAND ﬂash mem-
ory for our experiments. The block size of the memory is 64 KB and the page size
is 512 B. Even though JFFS2 supports NAND ﬂash memory, it doesn’t manage
bad blocks and has longer mounting time than YAFFS because of checking ﬁle
A Flash File System to Support Fast Mounting 423
Fig. 8. PXA255-Pro III board speciﬁcation
consistency and performing garbage collection. So we compare the performance
of the proposed ﬁle system with that of YAFFS.
The performance metric was the mounting time. Since the mounting time
of ﬂash ﬁle system heavily depends on data size and ﬂash memory usage, we
evaluated performance by increasing the ﬂash memory usage. For experiments,
we created test data with reference to write access denoted as in . The average
ﬁle size is around 22KB and most ﬁles are smaller than 2KB.
4.2 Mounting Time Performance
Fig. 9 shows the average mounting times of YAFFS and the proposed ﬁle sys-
tem. We measured the mounting time by increasing the ﬂash memory usage
from 10% to 80%. The result explains that the mounting time for YAFFS is
uniformly high. This is because YAFFS should scan the entire ﬂash memory
regardless of ﬂash memory usage to construct the data structures. In contrast
Fig. 9. Mounting time comparison according to ﬂash memory usage
424 S.-H. Park, T.-H. Lee, and K.-D. Chung
to YAFFS, mounting time of proposed ﬁle system is in proportion to amount of
block info and metadata areas. So we improve the mounting time of YAFFS by
In this paper, we designed a new NAND ﬂash ﬁle system, which provides fast
mounting. To support fast mounting, we divide ﬂash memory into Location Infor-
mation Area and General Area. LIA is ﬁxed in location and includes the block ad-
dresses for important ﬁle system data except ﬁle data. During the mounting, we can
construct the data structures in RAM using the location information. GA includes
the real data for ﬁle system such as metadata, ﬁle data and block information.
We evaluated our proposed ﬁle system by experiments. According to results,
we improved the mount time by 64%–76% as ﬂash usage compared to YAFFS.
Although we do not mention in this paper, we are developing the eﬀective
wear-leveling algorithm suitable for embedded system. Also we are planning to
develop journaling mechanism in order to provide ﬁle system consistency against
sudden system faults.
1. T.R. Bird: Methods to Improve Bootup Time in Linux. In Proc. of the Ottawa
Linux Symposium (OLS). Sony Electronics (2004).
2. Two Technologies Compared: NOR vs. NAND.
C1DE21986D28/229/NOR vs NAND5.pdf
3. M. L. Chang, P. C. H. Lee, R. C. Chang: Managing Flash Memory in Personal
Communication Devices. Proc. of IEEE Symp. on Consumer Electronics (1997)
177–182 erlin Heidelberg New York (1996)
4. Mei-Ling Chiang, Paul C. H. Lee Ruei-Chuan Chang: Cleaning Policies in Mobile
Computers Using Flash Memory: Journal of System and Software ibr. 1 (1997)
5. David Woodhouse: JFFS: The Journaling Flash File System. Technical Paper of
RedHat inc. (2001)
6. YAFFS Spec. http://www.aleph1.co.uk/yaﬀs/yaﬀs.html.
7. M.Resenblum and J.K.Ousterhout: The Design and Implementation of a Log-
Structured File System: ACM Transaction on Computer Systems Vol.10. (1992)
8. Samsung Electronics: Advantages of SLC NAND Flash Memory.
9. Flash Filesystems for Embedded Linux Systems.
10. JFFS3 Design Issue.
11. YAFFS. http://en.wikipedia.org/wiki/YAFFS
12. Understanding the Flash Translation Layer(FTL) speciﬁcation. Intel (1997)
13. G. Irlam: Unix File Size Survey. http://www.base.com/gordoni/gordoni.html