A Flash File System to Support Fast Mountingfor NAND Flash Memory Based

Embedded Systems

Song-Hwa Park1, Tae-Hoon Lee1, and Ki-Dong Chung2

Dept. of Computer Science, Pusan National University,Kumjeong-Ku, Busan 609-735, Korea

1{downy25, withsoul}@melon.cs.pusan.ac.kr,2kdchung@pusan.ac.kr

http://apple.cs.pusan.ac.kr�

Abstract. In embedded systems, NAND flash memory is typically usedas a storage medium because of its non-volatility, fast access time andsolid-state shock resistance. However, it suffers from out-place-update,limited erase cycles and page based read/write operations. Flash filesystems 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 file are scattered through out flash memory. Therefore,these file systems should scan entire flash memory to construct the datastructures during the mounting. This means that it takes a long timeto mount such file systems on a large chip. In this paper, we design andpropose a new flash memory file system which targets mobile devices thatrequire fast mounting. We experimented on the file system performanceand the results show that we improve the mounting time by 64%–76%as flash usage compared to YAFFS.

1 Introduction

Embedded computing systems such as mp3 player, digital camera and RFIDreader should be able to provide an instant start-up time [1]. In these systems,flash memory is widely used as storage system because of its benefits. It is non-volatile, meaning that it retains data even after power is turned off and consumesrelatively little power. In addition, flash memory offers fast access times andsolid-state shock resistance. These characteristics explain the popularity of flashmemory for embedded systems.

There are two major type of flash memory according to the gate type andstructure of the memory cell: NOR flash and NAND flash. For NOR flash mem-ory, the page size is typically 1 byte, meaning that each byte can be read andwritten individually. For NAND flash memory, on the other hand, the page size

� This work was supported by the Regional Research Centers Program (ResearchCenter for Logistics Information Technology), granted by the Korean Ministry ofEducation & 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 offers higher read/write performance than NOR flashmemory. As a result, it is widely used as the secondary storage systems [2].

Despite the advantages of NAND flash memory, it has several hardware char-acteristics that make straightforward replacement of existing storage media dif-ficult. Firstly, it suffers 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 operationis required for rewriting the contents of a block. Secondly, it can not be read orprogrammed smaller than a page (e.g. 512B, 2KB). Lastly, blocks have limitedendurance 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 doneevenly to all blocks to avoid wearing out specific blocks which would affect theusefulness of the entire flash memory. This is usually named as wear leveling orcycle leveling [3][4].

As the conventional file systems cannot be applied directly to flash memoriesdue to above mentioned limitations, new flash file systems such as JFFS2 [5] andYAFFS [6] were developed. JFFS2 is a journaling file systems based on flash mem-ory that keep metadata to avoid errors and corruption.Files are broken into severalsmaller nodes,which contain the actual data.Whenupdate operation occurs, a newnode is created and the updated data is written to the node. Therefore, JFFS2 mustscan the entire flash memory space at mounting time to collect the scattered data.Then the collected data are reorganized in RAM. It takes a long time and memoryconsumption is enormous. YAFFS is the first file system that is designed specifi-cally for NAND flash memory and outperforms JFFS2 with respect to mount timeand amount of memory consumption. However, it also has a long mounting timeproblem because it scans the spare areas of every block to check validation of data.In cases of JFFS2 and YAFFS, the flash mount time heav-ily depends on the flashcapacity and stored data size.

Since flash chip capacity is increasing every year, the flash mounting time willsoon become the most dominant reason of the delay of system start-up time[8]. Our goal is to design and implement a fast NAND flash file system. Tosupport fast mounting, we keep the location of the required data such as blockinformation, metadata during the mounting.

This paper is organized as follows. In Section 2, we describe JFFS and YAFFS,the flash file systems, respectively. In Section 3, we present our proposed filesystem to support fast mounting. The evaluation results are presented in Section4, and the con-clusion is shown in Section 5.

2 NAND Flash File Systems

In this section, we introduce the flash file system, JFFS2 and YAFFS.

2.1 JFFS2

JFFS was originally developed for the 2.0 kernel by Axix Communications inSweden. It is a journaling file system designed for small NOR (≤ 32MB) flash

A Flash File System to Support Fast Mounting 417

memory. David Woodhouse and others improved JFFS and developed JFFS2which addresses the issues of JFFS by providing compression, automatic levelingand NAND flash mem-ory support [9].

JFFS2 consists of simply a list of nodes and log entries. Each node containsactual data to be inserted into files or delete instructions and a log entry containsinformation about write operations on file. Nodes are written to flash sequentiallystarting at the first block. When update operation occurs, the updated datais written to other place since JFFS2 is based on LFS (Log-structured FileSystem) to solve the out-of-place problem [8]. This makes the related nodes andlog entries on the same file scattered throughout the flash memory. In order tocollect the scattered data, JFFS2 scans all nodes and log entries to construct filesystem at mounting time. Also it checks the consistency and executes a garbagecollection thread during the mounting. The gar-bage collection thread copiesvalid 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 mainmemory.

Even though JFFS2 solved and improved the problems of JFFS, it has stillsome problems when applied to the NAND flash memory. Firstly, the arbitrarysize of jour-naling nodes causes a fragmentation of pages on NAND flash memory.Secondly, JFFS2 has faced the serious problems such as slow mounting andwasteful memory consump-tion as NAND flash chips become larger. To overcomethese problems, the JFFS3 [8] draft was issued and developed.

2.2 YAFFS [6][11]

YAFFS (Yet Another Flash Filing System) is the first file system designed specif-ically for NAND flash memory. It was designed and developed by Charles Man-ning of the company Aleph One. Instead of using a kind of translation layer suchas FTL on flash devices to emulate a normal hard drive, it places the file systemdirectly on the flash chips. Fig. 1 shows the organization of YAFFS. It workson a small NAND flash memory which consists of several blocks. Generally, asmall NAND flash memory is composed of 32 pages and each page has sparearea 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 flash in chunks. Each chunk is the samesize as a page and has a unique id (referred as chunkID). A chunk can hold eitheran object header or file data. If chunkID of a chunk is zero, the chunk holds anobject header which describes a directory, file, symbolic link or hard link. Other-wise, the chunks holds file data and the value of chunkID indicates the positionof the chunk in the file [12]. The spare area contains the information about thecorresponding chunk such as chunkID, serialNumber, byteCount, objectID andECC and others. When a chunk is no longer valid, YAFFS marks a particularbyte in the spare area of the chunk as dirty. When entire pages of a block aremarked as dirty, YAFFS erases the block and re-claim the space. If free space onthe device is low, YAFFS chooses a block that has some number of dirty pagesand 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 marksevery newly written chunk with a serial number that is monotonically increasing.Thereby when YAFFS scans the flash, it may detect multiple data chunks of onefile that have identical ChunkID. It can choose the latest chunk by taking thegreatest serial number. However, the data chunks are scattered throughout flashmem-ory, YAFFS should scan the entire flash memory at mounting time. Thismeans that the mounting time of YAFFS heavily depends on the flash capacityand 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 flash file 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 flashmemory capacity and amount of stored data. To satisfy this requirement, wepropose a file system architecture in flash memory as is shown in Fig 2. In caseof JFFS2 and YAFFS, the related data are spread all around flash memory. Thisscheme causes long mounting time. Therefore, keeping the location of the relateddata is the key to support fast mounting.

In the proposed architecture, the flash memory is managed as separated twoareas, Location Information Area (referred as LIA) and General Area (referredas GA). Es-pecially, LIA maintains the latest location information. It occupiesthe several groups of blocks and firstly read during the mounting. GA is theremaining area except LIA in flash memory. In this area, all sub-areas such asmetadata, data and block information are stored. Let us show the characteristicsof each sub-area one by one.

Location Information Area. LIA keeps the latest location information wherethe metadata and block status are written. LIA is set to a fixed size and usedin 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 flash file system architecture in flash memory

limitation of NAND flash memory I/O unit. Loc Info consists of block info andmeta data fields. Block info fields point to the location where the latest blockinformation are written. Array of meta data field stores the latest addresses ofthe metadata sub-area where the metadata are stored. The number of index inthe array limits the maximum number of files in the file system. In Fig. 2, themaximum number of files is 16,205.

General Area. GA includes all sub-areas such as metadata, file data andblock info. These sub-areas except data block are managed based on segmentunit. 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 files, 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 file 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 flash

file system. Unlike the conventional flash file system such as JFFS2 and YAFFS,the proposed file system contains file locations in metadata. Since all Meta Datastructures 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 thenewly updated status of all blocks in flash memory. For each block, Block Infokeeps the information of the number of pages in use, block status, block type andetc. as shown in Fig. 4. We make use of this information to determine policiessuch as new block allocation and garbage collection. When unmounting the filesystem, the latest Block Info structures are written to flash memory.

3.2 In-Memory Data Structures

A procedure which mounts the file system includes constructing of block statusand creating the data structure for object in RAM. A directory, file, hard linkand symbolic link are abstracted to objects. Object structures are created forrun-time support of operations on opened file and are managed by a list. Fora file, Fnodes forms a tree structure that speeds up the search for data chunksin a file. The memory consumption of the proposed file system is similar tothat 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 datastructures that contain the status of all blocks in flash memory. The Block Statusdata structures are created in RAM using the Block Info data. These containthe information of corresponding block information and are managed by usingan array. The index of an array denotes the corresponding block number. TheBlock Status in RAM reflects the change on block status in flash memory. TheFig. 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 inRAM. The 20th block status is changed as the pages in the block are allocatedfor write operation. When unmounting the file system, the updated Block Statusinformation is stored in block info area.

Object data structure. An object can be a directory, file, hard link or sym-bolic link. During the mounting, the Object structures are created in RAM byloading 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 flash memory. Modifications to the directory, file, hard link or sym-bolic link are reflected in the Object as they occur.

Fnode data structure. The file locations are maintained by a tree structureas described in Fig. 7. For a file, the Fnode data structures are created in RAMfor managing its data location. The Fnode structures form a tree structure thatspeeds up the search for data chunks in a file. Depending on where it is in thetree, 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 file is created, it is assigned only one low-level Fnode. When the fileexpands past what a single Fnode can hold, then it is assigned a second Fnodeand an internal node is added to point to the two Fnodes. As the file grows,more low-level Fnodes and high level Fnodes are added.

4 Experimental Results

In this section, we evaluate the performance of the proposed file system.

4.1 Experiment Environment

We implemented our proposed file system and experimented using an embeddedboard. We used PXA255-Pro III board made by Huins. Fig. 8 summarizes thePXA255-Pro III board specification. We used 64 MB Samsung NAND flash mem-ory for our experiments. The block size of the memory is 64 KB and the page sizeis 512 B. Even though JFFS2 supports NAND flash memory, it doesn’t managebad blocks and has longer mounting time than YAFFS because of checking file

A Flash File System to Support Fast Mounting 423

Fig. 8. PXA255-Pro III board specification

consistency and performing garbage collection. So we compare the performanceof the proposed file system with that of YAFFS.

The performance metric was the mounting time. Since the mounting timeof flash file system heavily depends on data size and flash memory usage, weevaluated performance by increasing the flash memory usage. For experiments,we created test data with reference to write access denoted as in [13]. The averagefile size is around 22KB and most files are smaller than 2KB.

4.2 Mounting Time Performance

Fig. 9 shows the average mounting times of YAFFS and the proposed file sys-tem. We measured the mounting time by increasing the flash memory usagefrom 10% to 80%. The result explains that the mounting time for YAFFS isuniformly high. This is because YAFFS should scan the entire flash memoryregardless of flash memory usage to construct the data structures. In contrast

Fig. 9. Mounting time comparison according to flash memory usage

424 S.-H. Park, T.-H. Lee, and K.-D. Chung

to YAFFS, mounting time of proposed file system is in proportion to amount ofblock info and metadata areas. So we improve the mounting time of YAFFS by64%–76%.

5 Conclusions

In this paper, we designed a new NAND flash file system, which provides fastmounting. To support fast mounting, we divide flash memory into Location Infor-mation Area and General Area. LIA is fixed in location and includes the block ad-dresses for important file systemdata except file data.During themounting,we canconstruct the data structures in RAM using the location information. GA includesthe real data for file system such as metadata, file data and block information.

We evaluated our proposed file system by experiments. According to results,we improved the mount time by 64%–76% as flash usage compared to YAFFS.

Although we do not mention in this paper, we are developing the effectivewear-leveling algorithm suitable for embedded system. Also we are planning todevelop journaling mechanism in order to provide file system consistency againstsudden system faults.

References

1. T.R. Bird: Methods to Improve Bootup Time in Linux. In Proc. of the OttawaLinux Symposium (OLS). Sony Electronics (2004).

2. Two Technologies Compared: NOR vs. NAND.www.m-sys.com/NR/rdonlyres/24795A9E-16F9-404A-857C-C1DE21986D28/229/NOR vs NAND5.pdf

3. M. L. Chang, P. C. H. Lee, R. C. Chang: Managing Flash Memory in PersonalCommunication 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 MobileComputers Using Flash Memory: Journal of System and Software ibr. 1 (1997)108–121

5. David Woodhouse: JFFS: The Journaling Flash File System. Technical Paper ofRedHat inc. (2001)

6. YAFFS Spec. http://www.aleph1.co.uk/yaffs/yaffs.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)pp.26–52

8. Samsung Electronics: Advantages of SLC NAND Flash Memory.http://www.samsungelectronics.com/

9. Flash Filesystems for Embedded Linux Systems.http://linuxjournal.com/node/4678/.

10. JFFS3 Design Issue.http://www.linux-mtd.infradead.org/tech/JFFS3design/

11. YAFFS. http://en.wikipedia.org/wiki/YAFFS12. Understanding the Flash Translation Layer(FTL) specification. Intel (1997)13. G. Irlam: Unix File Size Survey. http://www.base.com/gordoni/gordoni.html