Design of a Reliable NAND Flash Software for Mobile Device TaeHoon Kim*, KwangMu Shin ** , TaeHoon Lee***, KiDong Jung **** * ** *** ****Department of Computer Science Pusan National University *[email protected] {**omega ***withsoul}@melon.pusan.ac.kr ****[email protected]

Abstract Flash memory in various embedded systems such as the backing memory is frequently used in an active type of RFID reader. Because batteries are used in a shifting environment and shifting is seriously considered, embedded systems receive a lot of influence by power failure while using and shock from outside environment. In order to manage efficiently flash memory, the use of flash file system is needed. When an error occurs, fast mounting and recovery are essential factors. This paper suggests appropriate constitution of NAND flash memory for fast mounting and recovery and also explains the way of recovery when a crash occurs. As the experiment is achieved in a light weight and in the optimized administrative environment system, efficiency can be quiet improved in the whole system

1. Introduction The ubiquitous society is practically used in various fields- medical care, education, flow of physical distribution, family etc. The locking of a gas valve or the cooking of an electric rice cooker by mobile phone can also be directed. Especially, the use of RFID in the physical distribution fields is rising up as a main technology for materialization of a ubiquitous society. Take a good look at the flow of the use of RFID technology in the physical distribution. Tag information of a commodity is received by the RFID reader in real time, and the reader again goes through a process of managing the data by forwarding this tag information to the main server. However, in this process the mobile machinery and tools which are used as the last equipment use battery and have the limits of portable type sudden power suspension and unstable This work was supported by the Regional Research Centers Program, grated by the Korean Ministry of Education & Human Resources Development

network connection. Because of above-mentioned

problems, the utility of the data can go down. Therefore, efficient settlements against various situations which can occur are needed. When sudden power failure or crash occur, fast booting of the administration system and fast recovery of the file system is essential. When a power failure occurs, the last equipment's quick booting is required for reducing the loss to the minimum, the time of a file system's mount occupies the proper part of the booting time. Especially, when a crash occurs, the booting can greatly expand by the size and used quantity of the file system. Therefore, quick mount of a file system through fast recovery is needed. When a problem occurs in the network connection, in order to reduce the loss of tag data, reader saves the tag data which is read in a real-time. When the connection is successfully achieved, reader forwards it to the server. Flash memory is usually used as the backing memory in a reader. There are the NOR type and NAND type of a flash memory[1]. Fast reading and random access are possible for the NOR type. NOR type slowly write and is very expensive. On the other hand, NAND type is faster in speed when using and its accumulation rate is high and its cost is lower compared with NOR. Therefore, in the file system of high capacity where data's input and output is frequent, NAND flash memory is more appropriate. Therefore, we used NAND flash memory as the standard in this paper. When a system problem occurs in the existing linux file system, the inconsistent inode is found and solved by using fsck. However, fsck performed time is in proportion with the size and the number of the whole file system. Therefore the restoration time for the recovery of the consistency gets longer. According as the restoration time, overhead becomes larger. That becomes a fatal defect for embedded systems where huge capacity system of fast mounting is needed. The recent Journaling File System which is the application of the transaction ability of database to the file system is a technique which is receiving the spotlight for reducing recovery time and overhead. For this Journaling File System uses the reservation of a regular area of the disk as the log area. If this is

Proceedings of The Sixth IEEE International Conference on Computer and Information Technology (CIT'06) 0-7695-2687-X/06 $20.00 © 2006

applied to a NAND flash file system, the in-place update can't take place for a flash memory and the unit of deleting differs from the unit of reading and writing. A new construction different from the already existing file system is needed for applying Journaling. Therefore, the constitution needed for fast mounting and recovery which are appropriate for NAND flash file system is suggested in this paper. In section 2, the research related with journaling is explained. In section 3, the application of journaling and the constitution of the flash file system which this paper suggests is explained. In section 4, the experimental results of the actual RFID reader environment is presented and the conclusion is presented on section 5.

accomplishment is complete. The actually performed file system content is written in the disk. Therefore, an error occurs in the file system, the log file replays. Thus maintaining the system's consistency and the recovery possibility grow. When the file system mounts, the whole checking of the file system is not needed so faster recovery and mount are possible. It is in proportion with the whole file system and the disk's regular area is used as the journal area. When mount occurs, the journal area is assigned. When normal unmount occurs, the journal area is deleted. At present the file systems which are applying for journaling are SGI's XFS, IBM's JFS, NameSys"s ResierFS, Ext3 applied Journaling on Ext2 and JFFS journaling applied to flash file system..

2. Background

3. Design Goal

In the following paragraph the features of the technology fsck which is used for recovery of the existing linux file system's meta data and the journaling file system used for covering disadvantage of fsck is explained. We have a look at the features of a flash memory

Generally the JFFS2 is being used in a way where journaling is applied for. Therefore, when a crash occurs, the file system's consistency is maintained through the log data. The mount speed is slow because log data which are spread out on the whole flash memory should be checked. In the case of YAFFS[6][7] which is used exclusively a lot as NAND, scan of the whole system has to be performed to establish whole file system. Because the technique of journaling cannot be applied, when a crash occurs in the file system, efficient disposal is very difficult. Therefore, our file system which includes terminal distribution have developed for applying the generally embedded system which uses NAND flash memory. Our goal of the design is as follows ˍ Providing high trust of embedded system ˍ Reducing mount time through efficient management of file system ˍ Recovery of consistency through fast recovery when a crash occurs ˍ High quality inner constitution Generally the embedded system uses batteries and has weak points which are a power failure or an unpredictable obstacle could occur due to the easy exposure to outside environments. RFFS performs all calculations atomically and makes fast recovery of the error which occurred unpredictably. Especially, it applies the reduced recovery overhead of the system for the security of the most important atomic calculation in the file system. Thus it applies for the overall utility of the file system to be highest and makes quick mount possible by not scanning the whole flash memory such as the YAFFS which exists in the step of establishment of the file system. In figure 1,

2. 1 FSCK(FileSystem Check) In the file system all the data are managed in the access possible state and organized state. If an error occurs in the existing linux System, there is a possibility of the breaking of the consistency of the meta data. The file system has to maintain the consistency of the meta data. fsck [3] in linux has traditionally been used for restoring the broken consistency of the meta data. Fsck checks perfectly the consistency of all the meta data; however, in the case of a huge file system it has to perform the 5 steps of the process on the meta data and a lot of time is needed. Therefore, fsck's overhead becomes a fatal defect in systems that need fast procedures.

2.2 Journaling FileSystem The Journaling File System[4][5] was designed to overcome the weakness of fsck. The Journaling File System is maintained in a regular area of the file disk which is known as log or journal. Whenever there is a calculation being updated or recorded in the file system the contents are recorded in log. In log, not only the calculation name but also the numerical information of the contents before performing calculation is recorded. Operation joined together many atomic operation is managed as transaction and commit is performed when

Proceedings of The Sixth IEEE International Conference on Computer and Information Technology (CIT'06) 0-7695-2687-X/06 $20.00 © 2006

file system and individually Transaction management, Log management, Recovery Algorithms exist.

data page number

Location Infomation Area

Data Area(journal log, data, meta data, block_info)

Recovery Algorithms Log Managemen

meta data page

File System

Transaction Managemen

Figure 1. The architecture for journaling file system When a log management is directly altered through the directory or file calculation, it is recorded in the flash memory and produces log. Transaction management guarantees the atomic performance against each calculation and produces transaction list of the occurring calculation. If a crash occurs the error can be restored through the Recovery Algorithms.

4. Design of the File System 4.1 File System Architecture in Flash memory We designed the file system architecture in flash memory as figure 1 With respect to metadata, JFFS2 and YAFFS spread them all around flash memory. This scheme causes long mount time. Therefore, to keep the location of the related data is the key to support fast mount. In the proposed architecture, the flash memory is managed as separated two areas, Location Information Area and Data Area. Especially, LIA maintains the latest location information. It occupies the first two groups of blocks (referred as segment) and firstly scanned during mount. DA is the rest area except LIA in flash memory space. In this area, all types of subareas such as metadata, log, data, blocks_into are stored according to wear-leveling algorithm. Let us show the characteristics each sub-area one by one. 4.1.1. Location Information Area. LIA keeps the latest location information for sub-areas except data. At each moment, only one page is valid. RFFS can improve the mount time making use of this information. At present, LIA is set to fixed size by two segments and we are planning to support dynamic change according to the erasing rate compared with DA. However, this area stores only sub-area addresses except unmount

unmount_flag journal_log 1 journal_log 2 block_info 1 block_info 2 meta_data 1 meta_data 2 ... meta_data m

data page number

journal log block number meta data block number

Block_info data block

location information block

meta data block

free block

journal log block

block_info block

meta data block number

Figure 2. RFFS architecture in flash memory flag and the sub-area consist of multiple blocks. Therefore, even though we use fixed size LIA, we are not expecting that the erasing rate increases rapidly. 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 limitation of NAND flash memory I/O unit. That is, RFFS maintains all kinds of location addresses in the same Loc_Info to make use of the limitation as possibly. Loc_Info consists of unmount_flag, journal_log, block_info and meta_data fields. Except unmount_flag, all the fields make pointer to sub-areas which store the real data. Unmount_flag and journal_log is for journaling and file system recovery. Block_info fields pointer to the Block_info segments of DA, which keeps the latest flash memory block status. Array of meta_data field stores the addresses of the metadata segment, respectively. The number of index in the array limits the maximum number of files in the file system. 4.1.2. Data Area. DA includes all sub-areas such as log, meta, file data, block status. These sub-areas except data block are managed based on segment unit, and the valid sub-areas are excluded from garbage collection. However, when RFFS allocates new segment for specific sub-area, it allocates new one using wear-leveling algorithm. This algorithm is only applied to invalid sub-areas or all data blocks. Let us show the characteristics of each sub-area. l o g [ 1 ] fi e l d o f L I A A lo g s e g m e n t o f K b l o c k s

b lo c k w r i ti n g d ir e c t i o n

Figure 3. One of log segment and write operation First, log sub-area contains logs which record write operations to recover file system in case of file system fault. When a write operation occurs, relocated metadata block address, serial number, commit flag are stored in log structure. The log sub-area consists of two separated segments. If one of them becomes full, the

Proceedings of The Sixth IEEE International Conference on Computer and Information Technology (CIT'06) 0-7695-2687-X/06 $20.00 © 2006

other is used alternately(figure 3). Shortly, the full segment becomes invalid when the related transactions are committed. The invalid log segment is collected by the garbage collector. Second, metadata sub-area consists of a number of independent segments. The maximum number is limited by the meta_data array of Loc_Info in LIA. RFFS stores all metadata for objects such as file, directory, and link in this area and constructs data structures in RAM during mount. Unlike the conventional flash file system such as JFFS2 and YAFFS, RFFS contains file location information in metadata. Because, in small block size flash memory, I/O unit is page, file splits into pages in proportion to the file size. For very large file, RFFS may request several metadata pages to contain all the page address. Figure 4 shows the inverse linked listed metadata pages for a large file. In the figure, the most left-side metadata page directly point to the related data pages in flash memory and it cannot recognize the existence of the rest metadata pages owing to inverse linked list structure. However, because all metadata pages belong to metadata sub-area, RFFS can constructs the complete data structures in RAM after mounting. As mentioned above, the latest addresses of metadata segments are kept meta_data array of Loc_Info in LIA area. After RFFS allocate a new meta-data segment, RFFS records the segment address in meta_data array. In case of the array is full, RFFS removes one of the segments using garbage collection. Then, RFFS assigns new segment using wear-leveling algorithm, next, it updates the new address on the correspondent index of the array. Byte

Meta page

Meta page

Meta page

Information

4

File Id

4

File Type

4

Parent directory of file

...

...

4

File size

4

Equivalent object Id

4

Location of the previous meta

4

Location of the data chunk 1

...

...

4

Location of the data chunk n

Figure 4. Example of management of the very large file using linked-listed metadata pages Third, block_info sub-area stores the Block_info data structure that contains the status of all blocks in flash and the newly updated block status. For each block, Block_info keeps the number of pages in use, block status, block type, bad block flag, etc. as shown in figure 5. RFFS makes use of this information to determine policies such as new block allocation, and garbage collection. Although RFFS actually manages the Block_info data structure in RAM, RFFS copies this to flash memory periodically to provide flash memory reliability. To save flash memory consumption, RFFS backups the whole Block_info

structure at a long interval and frequently stores block status changes between the intervals. Once the whole Block_info is written, the pages con-taining the previously stored Block_info structure gets invalid. typedef struct { unsigned softDeletions:6; unsigned pagesInUse:5; unsigned blockState:3; unsigned blockType:2; unsigned needsRetiring:1; unsigned eraseCount:6; } rffs_BlockInfo;

…

…

page

…

Block_info

Figure 5. Block_info data structure containing status of all blocks in flash memory

4.2 Atomic Transaction Operations At RFSS, when file system operation such as create, copy, move happens, each operation is managed by Transaction unit and also managed by linked-list to each transaction. Further, each transaction acquires its own lock and maintained by list on memory until transaction is committed. The overall flow of transaction is shown at Fig.6. First, execute read-ahead about accomplished operation and data are sustained on the memory. Changes about the data are done and when committed, write-back methods, which collect accomplished operations by regular period and then document them at once is executed. 40k buffering rate is the unit of write-back. In case of Block device, as data are sent to flash memory at the rate of 4k from kernel, the meta-data should be renewed by 4k rate at file system. However, as flash memory does not supply in-place-update, it continues renewing meta-data at different pages. As a result, by accomplishing buffering writing at the rate of 40k, we can reduce overall-used number of pages and input/output burden.

Figure 6. Example of transaction flow

4.3 The Log RFFS uses logging for fast recovery at system fault[12][13]. Logging means storing the information of operation when the operation works. Figure 7 shows the flow diagram of RFFS logging. In the figure, logging is individually performed by transaction

Proceedings of The Sixth IEEE International Conference on Computer and Information Technology (CIT'06) 0-7695-2687-X/06 $20.00 © 2006

manager. When logging is completed in log sub-area, then user requested operation is performed before file system operations. Therefore, logging does not been interfered from another operation and guarantees integrity of log data.

Figure 7. Example of log transaction flow

The core of idealization mechanism is to minimize the module copied to RAM at the booting stage. It means, boot loader's minimum modules for booting, kernel image made by kernel configuration optimization, basic root file system are copied to RAM. As a result, time taken for copy and decompression of RAM is reduced. In order to reduce the time for booting, unnecessary initialization process while boot loader stage and boot script of root file system area are removed. By accomplishing optimization, the kernel size has become reduced over 50%, from 1349188 byte to 615284 byte. Time for booting has also reduced from 43 seconds to 19 seconds. As a result, through the great reduction of the whole system's booting time and fast mounting of file system, we can maximize the capacity of the whole system.

Now, let us explain the recovery process. If unmount_flag in LIA is set to 0, RFFS scans log subarea to find the failed operation. Using the scanned log, the corresponding metadata data in metadata sub-area can be read. RFFS discards invalid or incomplete transaction and rolls back to previous state. Throughout this recovery, RFFS

5 Implementation and Performance In this paper, experiment was accomplished at the slimmed Linux kernel environment's experimental board. First, slimmed Linux kernel and experimental environment will be explained. Next, the experimental result will be discussed.

5.1. Light-Weight Kernel In embedded system, there are lots of resource limitations. Therefore, slimming process of existing embedded Linux is needed. Further, when applied to distribution terminal unit, such as RFID reader, short booting timing is also very important. If re-booting is required because of unexpected system failure, long time delay for normal operation would increase the distribution cost. Therefore, for the realization of fast booting under Linux system, we idealized each component of boot loader, kernel and root file system. Slimming process of embedded Linux is largely divided into the slimming of Linux kernel, slimming of root file system and slimming of boot loader. We slimmed Linux kernel through the linux kernel configuration optimization and slimmed boot loader by removing order mode for development. Finally, root file system passed through slimming process by reduction of binary command, library and so on.

Figure 8. Optimized light-weight kernel

5.2 Experimental Setup Environment to estimate the quality of the structure proposed in this paper is on Table 1. Hardware used in the experiment is extended board which has NAND flash memory adhered to PXA 255-pro 3 educational board(Huins). Flash memory of extended board is Samsung's 64MB product. We used 16kb blocks for flash memory. Each block is made up of 32 pages and each page's unit is 512byte Experiment is comparing the mounting speed among YAFFS, JFFS2(the most widely used journaling file system for flash memory) and the file system proposed in this paper. Moreover, by testing the mounting speed including error-recovering period, we can also measure time wasted for the recovery of the errors. Especially, as JFFS2 represents the journaling-applied file system, it can be compared with the journaling structure offered in this paper. First, measure time taken for mounting to compare the mounting speed. At first, measure the mounting time when used in 10%-using situation. Further, we measured the mounting time repetitively till it becomes 80%-using situation.

Proceedings of The Sixth IEEE International Conference on Computer and Information Technology (CIT'06) 0-7695-2687-X/06 $20.00 © 2006

experimentation environment Huins PXA255 Pro-3 Core Arm RAM 128Mb SDRAM Flash Memory NAND 64MB BootLoader BusyBox Kernel 2.4.19 Moreover, in order to compare the recovering speed, when errors such as power fail occur, we generated artificial errors and measured mounting time. When the error occurs, we can compare the recovering speed as RFFS and JFFS2 both supply journaling through log file.

5.3 Performance In the first experiment, we measured mounting speed by increasing the usage 10% each time. Mounting time on each file system has also been measured. JFFS2 has a drawback. It is that the whole file system should be scanned for mounting. As a result, the mounting time will be usage-constant. RFFS, the file system proposed in this paper, does not scan the whole file system and accomplish mounting by reading metadata and block information gathered in specific area. That's why the mounting time is significantly reduced. In figure 9, we can recognize that RFFS is much faster than JFFS2. JFFS2 takes considerable time even the usage is only 10% and as the usage increases, the mounting time also increases. RFFS is usage-constant and the whole mounting time is comparatively short. Our second experiment was to measure mounting speed when errors occurred, increasing usage by 10%. When errors such as power fail take place, Journaling file system recovers the error at the mounting stage. Thus by measuring mounting time when errors happened, we can also measure time for recovery. The result is that as two file systems use journaling, one file system doesn’t use journaling. The time journaling needed for recovery was very short. However, JFFS2 takes little advantage by journaling even if it accomplishes fast recovery, because the whole mounting time is long. In Figure 8, we compared the mounting time at normal situation and error-occurred situation. The result is that there is no perceptible difference between them.

Figure 9. Compare with JFFS2, YAFFS and RFFS

6. Conclusion In this paper, we proposed NAND flash file system which is possible for fast recovery and mounting. As flash memory is unable to use make a reservation for specific area, it should be changed to suitable structure for flash memory, not like the journaling file system already used. JFFS is the journaling file system applied to flash memory. However, it does not fit to the characteristic of journaling, which makes it possible for fast system mount. In this paper, by composing the allocated block by segment unit, we proposed the structure for fast mounting. Moreover, by supplying the atomic operation through the transaction supply, we could build the file system which is so much believable.

References [1] P. Cappelletti, C. Golla, P.Olivo, and E. Zanoni, Flash Memories. Kluwer, 1999 [2] David Woodhouse, “JFFS:The Journalling Flash File System” Technical Paper of RedHat inc. Oct. 2001. [3] Marshall Kirk McKusick “Fsck-The Unix File System Check Program” Technical Paper of University of Califonia, Berkeley [4] Ricardo Galli “Journal File System in Linux”, 2001 [5] Rechard Menedetter “Journaling Filesystems for Linux” [6] YAFFS Spec, http://www.aleph1.co.uk/yaffs/yaffs.html [7] http://en.wikipedia.org/wiki/YAFFS [8] Margo Seltzer, Keith Bostic "An Implementation of a Log-Structured File System for UNIX" Winter USENIX, January 25-29, 1993 [9] Mendel Rosenblum "The Design and Implementation of a Log-Structured File Sys-tem" 1995 [10] Holger Patecki, Peter Altenbernd, Michael Ditze, Reinhard Bernhardi-Grisson, “A Lightweight Linux Architecture for Resource-Limited Media Systems” [11] Tim R. Bird, “Methods to Improve Bootup Time in Linux”, Linux Symposium, 2004 [12] http://www.linux-mtd.infradead.org/tech/JFFS3design

Proceedings of The Sixth IEEE International Conference on Computer and Information Technology (CIT'06) 0-7695-2687-X/06 $20.00 © 2006