A Flash File System to Support Fast Mounting for NAND Flash Memory Based Embedded Systems Song-Hwa Park1,Tae-HoonLee1, 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, [email protected] 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 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.