A Flash File System to Support Fast Mounting for NAND Flash ...
Upcoming SlideShare
Loading in...5

A Flash File System to Support Fast Mounting for NAND Flash ...






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

A Flash File System to Support Fast Mounting for NAND Flash ... A Flash File System to Support Fast Mounting for NAND Flash ... Document Transcript

  • A Flash File System to Support Fast Mounting for 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, 2 kdchung@pusan.ac.kr http://apple.cs.pusan.ac.kr Abstract. In embedded systems, NAND flash memory is typically used as a storage medium because of its non-volatility, fast access time and solid-state shock resistance. However, it suffers from out-place-update, limited erase cycles and page based read/write operations. Flash file 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 file are scattered through out flash memory. Therefore, these file systems should scan entire flash memory to construct the data structures during the mounting. This means that it takes a long time to mount such file systems on a large chip. In this paper, we design and propose a new flash memory file system which targets mobile devices that require fast mounting. We experimented on the file system performance and 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 RFID reader 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 consumes relatively little power. In addition, flash memory offers fast access times and solid-state shock resistance. These characteristics explain the popularity of flash memory for embedded systems. There are two major type of flash memory according to the gate type and structure 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 and written individually. For NAND flash 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 offers higher read/write performance than NOR flash memory. 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 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 specific blocks which would affect the usefulness of the entire flash memory. This is usually named as wear leveling or cycle leveling [3][4]. As the conventional file systems cannot be applied directly to flash memories due to above mentioned limitations, new flash file systems such as JFFS2 [5] and YAFFS [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 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 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 memory consumption is enormous. YAFFS is the first file system that is designed specifi- cally for NAND flash 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 flash mount time heav-ily depends on the flash capacity and stored data size. Since flash chip capacity is increasing every year, the flash mounting time will soon 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. 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 flash file systems, respectively. In Section 3, we present our proposed file 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 flash file system, JFFS2 and YAFFS. 2.1 JFFS2 JFFS was originally developed for the 2.0 kernel by Axix Communications in Sweden. 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 JFFS2 which addresses the issues of JFFS by providing compression, automatic leveling and NAND flash mem-ory support [9]. JFFS2 consists of simply a list of nodes and log entries. Each node contains actual data to be inserted into files or delete instructions and a log entry contains information about write operations on file. Nodes are written to flash sequentially starting at the first 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 [8]. This makes the related nodes and log entries on the same file scattered throughout the flash memory. In order to collect the scattered data, JFFS2 scans all nodes and log entries to construct file 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 memory. Even though JFFS2 solved and improved the problems of JFFS, it has still some problems when applied to the NAND flash memory. Firstly, the arbitrary size of jour-naling nodes causes a fragmentation of pages on NAND flash memory. Secondly, JFFS2 has faced the serious problems such as slow mounting and wasteful memory consump-tion as NAND flash chips become larger. To overcome these 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 such as FTL on flash devices to emulate a normal hard drive, it places the file system directly on the flash chips. Fig. 1 shows the organization of YAFFS. It works on a small NAND flash memory which consists of several blocks. Generally, a small NAND flash 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 View slide
  • 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 same size as a page and has a unique id (referred as chunkID). A chunk can hold either an object header or file data. If chunkID of a chunk is zero, the chunk holds an object 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 position of the chunk in the file [12]. 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 flash, it may detect multiple data chunks of one file that have identical ChunkID. It can choose the latest chunk by taking the greatest serial number. However, the data chunks are scattered throughout flash mem-ory, YAFFS should scan the entire flash memory at mounting time. This means that the mounting time of YAFFS heavily depends on the flash 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 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 flash memory capacity and amount of stored data. To satisfy this requirement, we propose a file system architecture in flash memory as is shown in Fig 2. In case of JFFS2 and YAFFS, the related data are spread all around flash 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 flash 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 firstly read during the mounting. GA is the remaining area except LIA in flash 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 fixed 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 View slide
  • 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 and meta data fields. Block info fields point to the location where the latest block information are written. Array of meta data field 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 files in the file system. In Fig. 2, the maximum number of files is 16,205. General Area. GA includes all sub-areas such as metadata, file 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 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 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 flash 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 file system, 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 status and creating the data structure for object in RAM. A directory, file, hard link and symbolic link are abstracted to objects. Object structures are created for run-time support of operations on opened file and are managed by a list. For a file, Fnodes forms a tree structure that speeds up the search for data chunks in a file. The memory consumption of the proposed file 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 flash 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 reflects the change on block status in flash 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 file system, the updated Block Status information 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 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 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 structure as described in Fig. 7. For a file, 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 file. 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 file is created, it is assigned only one low-level Fnode. When the file 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 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 embedded board. We used PXA255-Pro III board made by Huins. Fig. 8 summarizes the PXA255-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 size is 512 B. Even though JFFS2 supports NAND flash memory, it doesn’t manage bad 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 performance of the proposed file system with that of YAFFS. The performance metric was the mounting time. Since the mounting time of flash file system heavily depends on data size and flash memory usage, we evaluated performance by increasing the flash memory usage. For experiments, we created test data with reference to write access denoted as in [13]. The average file 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 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 flash memory regardless 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 of block info and metadata areas. So we improve the mounting time of YAFFS by 64%–76%. 5 Conclusions In this paper, we designed a new NAND flash file system, which provides fast mounting. 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 system data except file data. During the mounting, we can construct the data structures in RAM using the location information. GA includes the 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 effective wear-leveling algorithm suitable for embedded system. Also we are planning to develop journaling mechanism in order to provide file system consistency against sudden system faults. References 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. 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 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) 108–121 5. David Woodhouse: JFFS: The Journaling Flash File System. Technical Paper of RedHat 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/YAFFS 12. Understanding the Flash Translation Layer(FTL) specification. Intel (1997) 13. G. Irlam: Unix File Size Survey. http://www.base.com/gordoni/gordoni.html