the integrity of a ﬁle system. The proposed ﬂash translation Application 1 Application 2 Application n
layer is implemented as a Linux device driver on a DaVinci
evaluation board  and evaluated with respect to ext2 and
Operating Systems API
ext3 ﬁle systems.
The experimental results show that 20% performance im-
provement can be obtained for ext2/ext3 ﬁle systems. More- File Systems (e.g., NTFS, EXT2)
over, the extra RAM consumption of the proposed FTL design
over ext2/ext3 is under 2.4% of existing designs.
Interface (e.g., ATA or SATA)
The rest of this paper is organized as follows: Section II
(e.g., Solid State Disks)
Flash Storage Devices
presents the system architecture and the motivation of this Flash Translation Layer
work. Section III presents ﬁle-system-behavior analysis and
proposes an efﬁcient ﬁle-system-aware FTL design. Section
IV summarizes the experimental results of the proposed FTL Memory Technology Device Layer
design over popular Linux ﬁle systems. Section V is the
conclusion. MLC MLC MLC
II. SYSTEM ARCHITECTURE AND RESEARCH
A. System Architecture Fig. 1. System Architecture
Consider a typical system architecture of ﬂash-memory-
based storage systems, as shown in Figure 1, where a ﬂash
storage device is usually connected to a host system through (VBA) and a block offset (page number). Its translation table
a standard interface. In order to control ﬂash media of a stores the mapping information from each given VBA to its
ﬂash storage device, a Memory Technology Device (MTD) PBA. The data is written to the PBA with the corresponding
driver is needed to support primitive ﬂash-memory opera- block offset. If the corresponding page is already used, a
tions, such as reads, writes, and erases. A Flash Translation new block is allocated, and the valid data in the previous
Layer (FTL) driver is used to provide advanced functionality block are copied to the new block with the new written
in address translation, garbage collection, and wear-leveling. data. NFTL  also adopts a block-level address translation
Here address translation is to translate any given logical block mechanism. The mapping mechanism is like BL, except that
addresses (LBAs) to physical block addresses (PBAs), where NFTL uses a replacement block to handle subsequent write
each LBA represents a storage unit of 512B. Note that data requests. The contents of the (over-written) write requests are
updates must be written to free pages of ﬂash memory such sequentially written to the replacement block. Therefore, an
that there is a need in address translation, and pages of old data entry in the address translation table stores two physical block
versions become invalid after each update. Garbage collection numbers, i.e., primary block and replacement block. When
is to reclaim space that store invalid data, whenever there are a replacement block is full, the replacement block and the
no sufﬁcient free pages. In other words, garbage collection corresponding primary block are merged into a new primary
selects victim blocks that contain invalid pages, copies valid block. The merge operation copies all of the valid data of
pages from the victim blocks to free pages (referred to as the primary block and replacement block to a newly allocated
live-page copyings), and then erases the victim blocks. Wear- primary block and erases the previous two blocks.
leveling is to distribute block erases as evenly as possible
over ﬂash-memory chips. An FTL driver usually emulates the
underlying ﬂash memory as a block device so that ﬁle systems B. Motivation
can access the ﬂash storage device transparently. Although NAND ﬂash memory has been widely adopted in
One increasing critical problem for users is that existing many storage-system designs due to various attractive features,
ﬁle systems, such as ext2 and ext3, are designed with little its application domains quickly grow beyond its original
awareness of ﬂash-memory characteristics. targets. A well-known example could be solid state disks
It is mainly because they are designed when hard drives (SSDs). Note that SSDs are used to replace the role of hard
(that rely on in-place updates) are the most popular secondary disks. Because the accessing of user and system data often
storage devices. Such an observation underlines our research generates many small-sized writes, those small-sized writes
motivation in the investigation of the design issues of FTL could quickly deteriorate the write performance of SSDs, due
drivers in reducing the potential overheads imposed by ﬁle to the out-place-update characteristics of ﬂash memory and its
systems on ﬂash memory. slow erase operations.
There are three major implementation approaches of ﬂash- As shown in Table I, in order to create a 64KB ﬁle in ext2,
memory management schemes: FTL, BL, and NFTL: FTL we need 11 write requests to different places, and only one of
adopts a page-level address translation mechanism for ﬁne- them is about the writing of some ﬁle contents. Most requests,
grained address translation , . It relies on an address except the request to the ﬁle contents, only access 8 LBAs per
translation table to map any given LBA to its PBA, where time. This observation implies harsh challenges on the designs
LBAs are the addresses of sectors which are accessed by of ﬂash-memory management schemes. Although FTL has
the operating system, and PBAs are the addresses of ﬂash good performance on random writes of small sizes, its page-
pages (which consists of two parts, i.e., the residing block level translation mechanism needs a huge translation table,
number and the page number in the block). BL adopts a block- which is often too large to ﬁt in the main memory. In order
level translation mechanism for coarse-grained translation. to resolve the size problem of translation tables, block-level
An LBA under BL is divided into a virtual block address translation mechanisms, e.g., NFTL and BL, are invented for
large-scaled ﬂash storage devices, e.g., SSDs. However, they File System
introduce considerable overheads of live-page copyings such IO Requests
that the system performance might be signiﬁcantly affected. File System Table
File System ext2 Metadata Userdata
Number of total write requests 11 Allocation
Metadata FTL Userdata FTL
Number of total write requests to metadata 10 Unit
Number of write requests to the ﬁle content 1
Number of accessed LBAs 196 IO Operations
Number of accessed LBAs to metadata 68
Number of accessed LBAs to the ﬁle content 128
Fig. 2. The System Modules of the File-System-Aware Management Scheme
C REATING OF A 64KB F ILE IN F ILE S YSTEMS
As shown in Figure 2, the proposed FTL design consists
of ﬁve components: ﬁle system identiﬁer, Metadata ﬁlter,
MLC ﬂash memory, instead of SLC ﬂash memory, is usually Metadata FTL, Userdata FTL, and Allocation unit. The ﬁle
selected as the storage media for low-cost embedded-system system identiﬁer is to identify the location of the ﬁle-system’s
solutions. However, pages of MLC ﬂash memory can only be metadata in the ﬂash storage device by analyzing the partition
written sequentially in a block, and partial-page programming table during the system’s start-up. As a result, whenever the
is prohibited4. Such a limitation introduces extra overheads metadata ﬁlter receives an I/O request, it can distinguish
to writes over ﬂash memory, and it might even make many metadata from userdata according to the accessed LBAs. If the
existing management schemes infeasible. For instance, FTL accessed LBAs are belonging to userdata, they are passed to
and NFTL need to invalidate a page by updating the status the userdata FTL where the userdata FTL adopts existing ﬂash-
bit of the spare area of a page, but the above constraints memory management schemes, such as FTL, NFTL, and BL.
of MLC ﬂash memory makes it impossible. Meanwhile, it If the accessed LBAs are in the metadata area, the metadata
is of paramount importance to maintain the sanity of ﬁle FTL is invoked to manipulate the underlying ﬂash memory.
systems because the endurance of MLC ﬂash memory is The metadata FTL adopts the proposed “MFTL” management
much lower than that of SLC ﬂash memory, and embedded scheme that adopts a ﬁne-grained address translation mech-
systems, especially portable devices, tend to run out of the anism, so that the overhead of address translation and the
battery during the run time. This research is motivated by number live-data copyings are reduced (Please see Section
the needs of performance and reliability enhancement over III-B). The MFTL requests free space in the unit of a block
I/O-intensive applications with the considerations of physical set, where a block set is a ﬁxed number of blocks. In order
constraints of MLC ﬂash memory. Our goal is to propose a to identify the version of stored data and to improve the
FTL (driver) design that better ﬁts ﬁle systems, so as to reduce performance on address translation, the last page of each block
the overheads introduced by ﬁle systems and to improve the set stores the version number and the mapping information of
sanity of ﬁle systems after power losses. The technical problem the block set (Please see Section III-C). In addition, the stored
is how to explore the attributes of ﬁle systems and their version number and the mapping information can also help to
access patterns with the considerations of write constraints recover the lost metadata of ﬁle systems so that the reliability
and the low reliability/performance problem of MLC ﬂash and sanity of ﬁle systems can be improved as well. The
memory. We should also explore the possibility in minimizing allocation unit is to manage free space. Whenever metadata
the number of live-page copyings caused by ﬂash-memory FTL or userdata FTL requests any free space, the allocation
management schemes. unit returns with the number of requested blocks. Once there
are not enough free blocks, the allocation unit initiates the
III. A FILE-SYSTEM-AWARE FTL DESIGN garbage collection to reclaim free space.
B. MFTL: A Metadata Management Scheme
In order to improve the performance and reliability of
ﬁle systems over MLC ﬂash-memory storage systems, we In this section, we will ﬁrst illustrate the general information
propose a ﬁle-system-aware FTL (driver) design, where the and layout of a ﬁle system because the design of a ﬁle system
characteristics of ﬁle systems are considered. In a ﬁle system, has a signiﬁcant impact on the performance of a storage
a systematic way is provided to organize data, and it usually system. We shall then provide some observations based on the
consists of two parts: metadata and userdata. Metadata contain access patterns of ﬁle systems and propose our approach in
the general information of the ﬁle system, e.g., the super- the handling of metadata. In this work, we propose to manage
block and inode tables in ext2 , and the attributes of ﬁles userdata with an existing ﬂash-memory management scheme,
and directories. Some modern journaling ﬁle systems might such as NFTL, and adopt our metadata management scheme
include journaling techniques to protect their metadata. Al- (MFTL) for metadata management.
though metadata usually take a small part of the space of a MFTL, which is implemented in the metadata FTL (as
storage system, it is frequently accessed with small sizes and shown in Figure 2), is speciﬁcally designed to manage the
therefore needs to be managed carefully. On the other hand, metadata of ﬁle systems efﬁciently. Note that different ﬁle
userdata stores the contents of ﬁles or user data. Compared systems do manage their general information in different ways.
to metadata, most userdata are less frequently accessed, and For example, ext2 divides the entire ﬁle system into several
each access to userdata often touches data of a larger size. block groups and uses two metadata structures, i.e. Superblock
and Group Descriptor Table (GDT), to describe the general
4 A 2KB page in SLC ﬂash memory can partially be programmed for four information of the ﬁle system (as shown in Figure 3). The
times. Superblock contains the basic information of the ﬁle system,
such as the block size, the number of blocks, and the number way to maintain the metadata should be different from user
of inodes per block group. The GDT is to manage the block data so as to improve the performance of the ﬁle system, due
group information, and each entry of the GDT maintains the to the out-place update characteristics of ﬂash memory.
information of one block group, e.g., the starting address The metadata ﬁlter of the proposed FTL (driver) design is
of each block group and the status of blocks and inodes. to identify I/O requests as metadata requests and userdata
Therefore, the layout of ext2 can be determined by scanning requests, where a metadata(/userdata) request is to access
its Superblock and GDT. Each block group has its own “inode data belonging to metadata(/userdata). The metadata ﬁlter
bitmap” and ”block bitmap”. Each bit in this bitmap indicates maintains a run-length structure for each metadata ﬁle in the
the allocation status of one data cluster or inode. Each block main-memory. As shown in Figure 5, each I/O request contains
group also maintains an inode table, and each inode of the information like S LBA and Length, where S LBA is
inode table describes the attributes of one ﬁle or directory in the ﬁrst LBA being accessed by the request, and Length
the group. is the number of consecutive LBA’s to be accessed. Based
on the information, the metadata ﬁlter determine which of
Table Block Group
metadata or userdata FTL will handle the request. If the
request is to access the content of a ﬁle or directory, it is
sent to the userdata FTL, that adopts an existing ﬂash-memory
a Block Inode
InodeTable File Content File Content management scheme, such as NFTL or BL.
Superblock Metadata Request
Fig. 3. The File Systems Layout S_LBA Length S_LBA Length M_type
I/O Request Group Descriptor Table
S_LBA Length S_LBA Length
Requests LBA Sectors Data Type User Request
(R/W) S_LBA Length
R 8 8 Group Descriptor Table
R 1976 8 Inode Bitmap
W 2 2 Superblock Fig. 5. Metadata Filter
W 8 8 Group Descriptor Table
W 1976 8 Inode Bitmap MFTL, that is implemented in the metadata FTL, adopts
W 1984 8 Inode Table a page-level address translation mechanism in a logging-
R 1968 8 Block Bitmap similar fashion. The page-level address translation mechanism
W 137296 128 File Content maintains one mapping entry for each page so as to reduce
W 6032 8 Directory the address translation overhead and live-data copyings. Since
W 2 2 Superblock metadata only occupy a small portion of ﬁle system, the
W 8 8 Group Descriptor Table memory requirement of the mapping table should be able to ﬁt
W 1984 8 Inode Table in most embedded systems MFTL writes data to a block from
W 1968 8 Block Bitmap its ﬁrst page one by one in a sequential way, i.e., a logging-
similar fashion. When there is no free space, MFTL requests
for another block set to store new or updated data, where a
Fig. 4. The Traces of Creating a 64KB File in ext2 block set is composed of a ﬁxed number of blocks (Please see
Section III-C). Metadata of different requests might be written
Before any access to a ﬁle or directory, the ﬁle system to ﬂash-memory pages in an interleaving way. The type of
might access related metadata to determine the system layout. metadata (i.e., M type as shown in Figure 5) is stored in the
The ﬁle system then accesses the metadata that contain the spare area of each page, so that the type of data stored in a
attributes of the accessed ﬁle or directory. If the ﬁle system ﬂash-memory page can be identiﬁed during the construction of
needs to allocate or de-allocate any data clusters, the ﬁle address translation tables. When a block set is about to ﬁll up,
system reads the corresponding bitmap structure to update the last page, referred to as a summary page, is written with a
the allocation status of the data clusters. Finally, the ﬁle version number and the page-level translation information of
system accesses the user data, i.e., the contents of the ﬁle the metadata stored in the block set. Therefore, the address-
or directory, and then updates the corresponding metadata if translation overhead and the number of live-data copyings for
needed. Figure 4 shows the access patterns in the creating frequently updated metadata can be reduced. The writing of a
of a 64KB ﬁle in ext2. In order to determine the ﬁle system summary page is also referred to as a “commit” action to the
layout, the Superblock and Group Descriptor Table in ext2 are writes of the corresponding block set.
accessed. In order to allocate data clusters to a newly created
ﬁle, the block bitmap in ext2 are accessed. In addition, the C. Reliability versus Commit Actions
corresponding ﬁle attributes must be inserted to the inode table Block management should take the reliability of ﬁle systems
in ext2. Since the ﬁle system status has been changed, the into considerations, especially for battery-driven embedded
updated information is written to the corresponding metadata systems. If a system crashes while data are written to a storage
to maintain the consistency of ﬁle system. It is observed that device, the ﬁle system in the storage device might be in an
the traces contain many write requests to Superblock and inconsistent state. In order to avoid the scanning of the entire
Group Descriptor table. ﬁle system during the recovery, some journaling technique
The above observations show that metadata of a modern is needed to protect sensitive data, such as metadata, where
ﬁle system are frequently accessed and are of small sizes. The a journaling technique usually keeps update information in
“safe” area for recovery purpose. For example, Ext3, i.e., a shaped scheme from their ﬁrst pages, and pages in a block are
journaling version of ext2, stores the journaling information sequentially written, the transmission time and programming
in some speciﬁc area in the unit of a transaction, which time of metadata in a block set can be signiﬁcantly reduced by
consists of a descriptor, updated metadata, and a committing writing multiple pages simultaneously. The read performance
status. Although the journaling technique is adopted by some can be also improved in a similar way.
ﬁle system to improve the integrity of a ﬁle system, it does
introduce a signiﬁcant amount of overheads, mostly in terms IV. PERFORMANCE EVALUATION
A. Performance Metrics and Experiment Setup
The purpose of this section is to evaluate the capability of
Metadata Metadata Metadata Summary Page
the proposed FTL (driver) design with FTL, NFTL, and BL
(implemented in the userdata FTL) over ext2 and ext3 ﬁle
Metadata Metadata Metadata
sysetms, in terms of performance improvement. The perfor-
Metadata Metadata Metadata
Summary mance improvement was based on the data transmission time
and the amount of live-data copyings.
The proposed FTL design was implemented on the DM644X
Fig. 6. A Block Set and its Summary Page DaVinci evaluation board to evaluate its performance under
ext2 and ext3 ﬁle systems. The DaVinci evaluation board
has 64MB on-board NAND SLC NAND ﬂash memory (32
The design of MFTL not only aims at the system perfor- pages per block and 512 bytes per page). The proposed
mance improvement but also introduces the idea of commit FTL design was implemented as a Linux device driver to
action for reliability considerations. Consider popular ﬁle control the on-board ﬂash memory. 50MB of the on-board
systems that do not support the journaling technique, such ﬂash memory was partitioned as an ext2 or ext3 ﬁle system
as FAT32 and ext2. With MFTL, writes to each block set and each block set (allocated to store metadata) consisted of
commit with a summary page for crash recovery, where MFTL two blocks. The capability of the proposed FTL design was
allocates free space in the unit of a block set. As shown in evaluated over some realistic cases and popular benchmarks.
Figure 6, inter-block link information is also maintained in The realistic cases were the real archive (linux-kernel header
the spare area of the ﬁrst page of each block to speed up the ﬁles) to evaluate the performance of the proposed FTL design
block traversal in a set, where two links are used to point over ext2 and ext3. Meanwhile, the benchmark “Bonnie++”
to its next block and the last block of the set, respectively. was used to further evaluate the performance over ext2 based
Pages of each block set are used to store metadata, except the on the industry practice.
summary page. Each summary page contains a 64-bit version
number to indicate the version of the block set and the page-
B. Performance Improvement
level translation information of the metadata in the block set.
Whenever the summary page of a block set is written, the 1) Data Transmission Time: Figure 7 shows the perfor-
block set is said being “committed”. When the ﬁle system mance improvement of the proposed FTL design with FTL,
crashes, MFTL will scan the summary page of each block set NFTL, and BL, compared with pure FTL, NFTL, and BL
to recover the translation information of metadata according management schemes. For example, the improvement ratios on
to their version numbers. If the system ﬁnds an uncommitted NFTL with small-ﬁle copyings and Bonnie++ benchmark over
block set, then every page in the block set must be scanned. the ext2 ﬁle system were 22% and 19%, respectively. Com-
Any partial programmed page in an uncommitted block set pared with the pure BL management scheme, which is widely
should be discarded because the system might crash during used in USB ﬂash drives, the performance improvement was
some data writing. For metadata stored in discarded pages, more than 30%. It was worth of mentioning that there was
their most recent versions in committed block sets should be no signiﬁcant improvement, compared with the pure FTL
used, where metadata in a committed block set are guaranteed management scheme, because the FTL management scheme
being correct. When a bad block occurs, the system should adopted a ﬁne-grained address translation mechanism for both
also adopt the most recent version of metadata in a committed userdata and metadata. However, the FTL management scheme
block set. The commit action of a block set can help in the is not practical in large-scale ﬂash memory because it needs
reliability improvement of ﬁle systems with or without the large RAM space to maintain the address translation table.
support of the journaling technique because their journaling 2) Live-Page Copyings: Figure 8 shows the number of
information might have a chance to get lost. The protection live-page copyings with different management schemes over
of metadata is improved by the commit action. Note that the ext2 and ext3. The proposed FTL design could reduce more
block-set size could have an impact on the space utilization than 30% of live-page copyings in most cases. However, the
and might affect the worst-case amount of lost data after the number of live-page copings of the proposed FTL design was
system crash. That is because the last page of each block set is higher than that of pure FTL management scheme under the
not used to store data, and parts of the data of an uncommitted testing of the Bonnie++ benchmark. This was because the
block set could be discarded. The selection of the block-set data accessed by Bonnie++ were relatively small, and most of
size is a trade-off between the space utilization and the degree them were metadata. Therefore, the proposed FTL design had
of reliability. to do garbage collection many times to release free pages for
When multi-chip and multi-channel designs are considered metadata and resulted in many live-page copings in metadata.
for better performance, the proposed management scheme do In contrast, the pure FTL management scheme could store
have good potential in parallelism. Each block of a block set metadata in any block of ﬂash memory, and the amount of
can reside in a different ﬂash-memory chip. Since metadata accessed userdata was relatively small so that the garbage
are circularly written to blocks of a block set in a ”z”- collection was not triggered.
mission time(s) For future research, we shall further explore the trade-
mission time (s)
off between the main-memory consumption and performance
improvement, especially for low-cost products. Multi-channel
FTL 200 NFTL
0 MFTL+FTL 0 MFTL+NFTL
Ext2 Ext3 Bonnie++ Ext2 Ext3 Bonnie++
system designs will also be exploited for huge-capacity ﬂash-
Small file copies Benchmark Small file copies Benchmark
memory storage devices for better performance and lower cost.
T Cases Test Cases
(a) FTL (b) NFTL
 K9NBG08U5M 4G * 8 Bit NAND Flash Memory Data Sheet, Samsung
ission time (s)
2500  NAND08Gx3C2A 8Gbit Multi-level NAND Flash Memory, STMicroelec-
1500 tronics, 2005.
 B. Carrier, File System Forensic Analysis. Addison Wesley Professional,
Ext2 Ext3 Bonnie++ 2005.
Small file copies Benchmark
 D. Woodhouse, “JFFS: The Journalling Flash File System,” in Ottawa
Test Cases Linux Symposium, 2001.
 L.-P. Chang and T.-W. Kuo, “An Adaptive Striping Architecture for
(c) BL Flash Memory Storage Systems of Embedded Systems,” in IEEE Real-
Time and Embedded Technology and Applications Symposium, 2002, pp.
Fig. 7. Comparisons on the Transmission Time with Different Management 187–196.
Schemes  L.-P. Chang, “On efﬁcient wear-leveling for large-scale ﬂash-memory
storage systems.” 22st ACM Symposium on Applied Computing (ACM
SAC), March 2007.
Live page copyings
10000 120000  Y.-H. Chang, J.-W. Hsieh, and T.-W. Kuo, “Endurance Enhancement
Live page copyin
80000 of Flash-Memory Storage Systems: An Efﬁcient Static Wear Leveling
4000 40000 Design,” the 44th ACM/IEEE Design Automation Conference (DAC),
2000 FTL NFTL
0 MFTL+FTL 0 MFTL+NFTL June 2007.
Ext2 Ext3 Bonnie++ Ext2 Ext3 Bonnie++  A. Kawaguchi, S. Nishioka, and H. Motoda, “A Flash-Memory Based
Small file copies Benchmark Small file copies Benchmark File System,” in Proceedings of the 1995 USENIX Technical Conference,
T C Test Cases Jan 1995, pp. 155–164.
 C.-H. Wu and T.-W. Kuo, “An Adaptive Two-Level Management for
(a) FTL Live-Page Copyings (b) NFTL Live-Page Copyings the Flash Translation Layer in Embedded Systems,” in IEEE/ACM
5000000 2006 International Conference on Computer-Aided Design (ICCAD),
Live page copyings
4000000 November 2006.
 J.-H. Lin, Y.-H. Chang, J.-W. Hsieh, T.-W. Kuo, and C.-C. Yang,
“A NOR Emulation Strategy over NAND Flash Memory,” the 13th
0 MFTL+BL IEEE International Conference on Embedded and Real-Time Computing
Ext2 Ext3 Bonnie++
Systems and Applications(RTCSA 2007), August 2007.
Small file copies Benchmark  “Flash File System. US Patent 540,448,” in Intel Corporation.
 L.-P. Chang and T.-W. Kuo, “An Efﬁcient Management Scheme for
Large-Scale Flash-Memory Storage Systems,” ACM Symposium on
(c) BL Live-Page Copyings Applied Computing (SAC), pp. 862–868, Mar 2004.
 Y. Du, M. Cai, and J. Dong, “Adaptive Energy-aware Design of a
Fig. 8. Comparisons on the Number of Live-Page Copyings with Different Multi-bank Flash-memory Storage System,” Proceedings of the 11
Management Schemes IEEE Conference on Embedded and Real-Time Computing Systems and
Applications (RTCSA’05), 2005.
 J.-W. Hsieh, T.-W. Kuo, P.-L. Wu, and Y.-C. Huang, “Energy-Efﬁcient
and Performance-Enhanced Disks Using Flash-Memory Cache,” pro-
V. CONCLUSION AND FUTURE WORK ceedings of ACM/IEEE International Symposium on Low Power Elec-
tronics and Design (ISLPED 2007), pp. 334–339, 2007.
This research is motivated by the signiﬁcant performance  L.-P. Chang, “Hybrid Solid-State Disks: Combining Heterogeneous
degradation of ﬁle systems, such as ext2 and ext3, when ﬂash NAND Flash in Large SSDs,” The 13th Asia and South Paciﬁc Design
memory is used as a storage medium. An efﬁcient ﬁle-system- Automation Conference (ASP-DAC), 2008.
aware FTL design is proposed to better manage the metadata  KFW8G16Q2M-DEBx 512M x 16bit OneNAND Flash Memory Data
of ﬁle systems for performance and reliability considerations. Sheet, Samsung Electronics, 09 2006.
 OneNAND Features and Performance, Samsung Electronics, 11 2005.
With careful system behavior analysis, it was observed that  Y. Joo, Y. Choi, C. Park, S. W. Chung, E.-Y. Chung, and N. Chang,
the access frequency and small size characteristics of metadata “Demand paging for onenandtm ﬂash execute-in-place.” CODES+ISSS,
introduce considerable overheads, e.g., live-page copyings, to October 2006.
ﬂash-memory management. A metadata ﬁlter is proposed to  “Flash Cache Memory Puts Robson in the Middle,” Intel.
separate metadata requests and userdata requests based on the  “Windows ReadyDrive and Hybrid Hard Disk Drives,
knowledge of the layout of ﬁle systems, and metadata are http://www.microsoft.com/whdc/device/storage/hybrid.mspx,”
Microsoft, Tech. Rep., May 2006.
managed with a ﬁne-grained address translation mechanism  “DaVinci Digital Media System-on-Chip - TMS320DM6446 http:
and written to ﬂash-memory pages in a logging-similar fashion //focus.ti.com/docs/prod/folders/print/tms320dm6446.html,” Texas In-
for performance and reliability considerations. An effective struments, Tech. Rep.
recovery scheme is then proposed to improve the integrity of  “Understanding the Flash Translation Layer (FTL) Speciﬁcation,
a ﬁle system. The effectiveness of the proposed scheme was http://developer.intel.com/,” Intel Corporation, Tech. Rep., Dec 1998.
analyzed with case studies over ext2/ext3 ﬁle systems. A series [Online]. Available: http://developer.intel.com/
 “FTL Logger Exchanging Data with FTL Systems,” Intel Corporation,
of experiments also shows that the performance of ext2/ext3 Tech. Rep.
ﬁle systems could be signiﬁcantly improved by more than  “Flash-memory Translation Layer for NAND ﬂash (NFTL),” M-Systems,
20%, in most cases, where only limited extra main-memory 1998.