The Effect of Absorbing Hot Write References on FTLs for
Flash Storage Supporting High Data Integrityy
Myoung Sub Shim In Hwan Doh Youngje Moon Hyojeong Lee
Hongik University
Seoul 121-791, Korea
{sms1222, ihdoh, yjmoon, hjlee}@mail.hongik.ac.kr
Jongmoo Choi
Dankook University
Seoul 140-714, Korea
choijm@dankook.ac.kr
Donghee Lee
University of Seoul
Seoul 130-743, Korea
dhl_express@uos.ac.kr
Sam H. Noh
Hongik University
Seoul 121-791, Korea
samhnoh@hongik.ac.kr
ABSTRACT
Flash storages are prevalent as portable storage in comput-
ing systems. When we consider the detachability of Flash
storage devices, data integrity becomes an important issue.
We consider the performance of Flash Translation Layer
(FTL) schemes in conjunction with ¯le system behavior that
pursue high data integrity. To assure extreme data integrity,
¯le systems synchronously write all ¯le data to storage ac-
companying hot write references. In this study, 1) we con-
centrate on the e®ect of hot write references on Flash stor-
age, and 2) we consider the e®ect of absorbing the hot write
references via nonvolatile write cache on the performance of
the FTL schemes in Flash storage. In so doing, we quantify
the performance of typical FTL schemes for workloads that
contain hot write references through a wide range of exper-
iments on a real system environment. Results show that
for workloads with hot write references FTL performance
does not conform with previously reported studies. We also
conclude that the impact of the underlying FTL schemes
on the performance of Flash storage is dramatically reduced
by absorbing the hot write references via nonvolatile write
cache.
Categories and Subject Descriptors
C.3 [Computer Systems Organization]: Special-Purpose
And Application-Based Systems|Real-time and embedded
systems; D.4.2 [Operation Systems]: Storage Manage-
ment|Storage hierarchies
General Terms
Experimentation, Measurement, Performance
Keywords
Flash Translation Layer (FTL), Flash memory, File System,
Metadata
1. INTRODUCTION
Flash storage such as USB Flash drives are widely used
as portable storage in commodity computer systems. When
yThis work was supported by the Korea Science and En-
gineering Foundation(KOSEF) grant funded by the Korea
government(MOST) (No. R0A-2007-000-20071-0)
we consider the detachability of Flash storage devices, data
integrity becomes an important issue. In this study, we
look into the performance e®ects of Flash Translation Layer
(FTL) schemes when ¯le systems provide high data integrity
to Flash storage devices.
As Flash memory technology is mature, Flash storage
such as USB Flash drives and SD (Secure Digital) Cards are
prevalent in various computing environments. Flash storage
normally adopts an FTL to e±ciently manage the underly-
ing Flash memory. As the e±ciency of FTL dominates the
performance of Flash storage, issues related to improving
FTL performance have been the focus of much research [12,
13, 15].
In addition to the I/O performance enhancement of Flash
storage, it is important to assure the data integrity stored in
Flash memory against system crashes such as sudden power
failure or unexpected removal of the Flash storage. As Flash
storage devices may be removed at any time, conventional
operating systems such as the Windows XP provide options
to disable the volatile write cache for better reliability of
removable storages. Hence, to assure high data integrity, ¯le
systems may possibly write all the ¯le data and metadata
synchronously choosing to sacri¯ce write performance.
E®orts of ¯le systems to support high data integrity may
cause di®erent e®ects on the performance of Flash storage
according to the FTL schemes adopted in the Flash stor-
age. The synchronous write requests for ¯les is accompa-
nied with hot write references for the ¯le system metadata.
These hot write references may be tolerable for some FTL
schemes, while for others, these may lead to unacceptable
write performance. To support high data integrity without
performance degradation, various forms of nonvolatile write
cache may possibly be adopted to absorb these hot write
references. Again, this e®ort may cause di®erent e®ects on
di®erent FTL schemes in terms of execution performance.
In this study, we evaluate the performance of typical FTL
schemes in regards to synchronous writes issued by the VFAT
¯le system on a real experimental environment. Through ex-
periments, we quantify and analyze the e®ect of absorbing
the hot write references via Nonvolatile RAM (NVRAM)
on the FTL schemes. Employing NVRAM also allows the
¯le system to ensure high data integrity of Flash storages
without sacri¯cing performance.
The experimental results show that, ¯rst, the FTL schemes
performs di®erently from what has been previously reported.

(a) Replacement (b) Log
Figure 1: Comparison of Replacement block scheme
and Log block scheme for two update request se-
quences to LBN 0x08.
Speci¯cally, for some situations the Log block scheme shows
worse performance compared to the Replacement block scheme,
while for some others the FAST scheme underperforms the
Log block scheme due to the hot write references generated
by synchronous ¯le writes. Second, by absorbing the hot
reference pattern, the performance of the FTL schemes can
be dramatically improved, while at the same time, the per-
formance gap among the FTL schemes may be reduced con-
siderably.
The remainder of this paper is organized as follows. In the
next section, we brie°y review related works and the FTL
schemes that we consider. Then, in Section 3, we present
the methodology for absorbing hot write references that was
used in our experiments. In Section 4, we describe the hard-
ware setup, software implementation, and workloads for our
evaluation. We discuss the experimental results in Section
5. Finally, in Section 6, we conclude with a summary and
directions for future research.
2. RELATED WORKS AND BACKGROUNDS
In this section, we present some previous works related to
this study. Then the workings of the FTL schemes that we
consider in this study are described.
2.1 Related Works
Much research has already been conducted on issues re-
lated to improving the performance of the Flash Translation
Layer (FTL). The various FTL schemes can generally be
classi¯ed into three categories, that is, block-mapped FTL,
page-mapped FTL, and hybrid-mapped FTL. The block-
mapped FTL manages the address mapping table in block
units (that is, the erase unit in Flash memory). A represen-
tative scheme of the block-mapped FTL is the Replacement
block scheme proposed by Ban [4]. Although the Replace-
ment block scheme is ine®ective when frequent update re-
quests for the same location occurs, this scheme consumes
low system resources such as memory and CPU time due to
its simplicity.
The page-mapped FTL allocates a free page for a write
request by retaining an address mapping table in page units
(that is, the program unit in Flash memory). A represen-
tative scheme of the page-mapped FTL was proposed by
M-Systems [5]. Although the page-mapped FTL uses all
the pages in a block without waste, it requires considerable
system resources to maintain the page address mapping in-
formation and to reclaim free blocks, that is, garbage collec-
tion.
The hybrid-mapped FTL tends to adopt merits from both
(a) Log (b) FAST
Figure 2: Comparison of Log block scheme and
FAST scheme for two update requests to LBN 0x08
and 0x10 in sequence.
the block-mapped FTL and page-mapped FTL so that it
pursues high performance while requiring reasonable resources.
Some typical hybrid-mapped FTL schemes are the Log block
scheme proposed by Kim et al., the FAST scheme proposed
by Lee et al., and the adaptive two-level management scheme
proposed by Wu et al. [12, 13, 15].
The performance of FTL schemes are very closely related
to the behavior of the underlying ¯le system. However, most
studies related to FTL schemes have been simulation based
studies, concentrating on the performance of FTL schemes
independent of ¯le system behavior. Di®erent from these
previous works, we evaluate the FTL schemes on a real sys-
tem environment, and the performance of the schemes are
evaluated in conjunction with a ¯le system behavior, in par-
ticular, when the ¯le system pursues high data integrity.
The FTL schemes that we consider in this study are the
Replacement block scheme, the Log block scheme, and the
FAST scheme. The Replacement block scheme su®ers in
performance with hot write references as mentioned before.
Although the Log block scheme appears to overcome the
weakness of the Replacement block scheme, it still may suf-
fer from low utilization of log blocks when frequent random
update requests come across a wide range of blocks. In turn,
the FAST scheme appears to resolve the weakness of the Log
block scheme. A detailed explanation of these three FTL
schemes are presented in the following subsection.
2.2 FTL Schemes Considered
For a better understanding of our work, the overview of
the three schemes that we consider is presented focusing on
their di®erences. We ¯rst present the di®erences between
the Replacement block scheme and the Log block scheme.
Then, we describe the di®erences between the Log block
scheme and the FAST scheme.
Figure 1 illustrates the distinct actions taken for the Re-
placement block scheme and the Log block scheme for a
scenario of operations. In the scenario, the FTL schemes
process two consecutive update requests for the same Log-
ical Block Number (LBN) 0x08 in Flash memory and, in
turn, an update request for LBN 0x10 in another block. Ini-
tially, both FTL schemes retain a data block containing the
LBN 0x08 and this data block has neither a replacement
block nor a log block
For this scenario, each of the Replacement block scheme

and the Log block scheme operates as shown in Figure 1(a)
and (b), respectively. For the two updates for the LBN
0x08, speci¯cally, the Replacement block scheme allocates
a replacement block and writes the new data on the same
o®set of the replacement block for the ¯rst update, and then
in sequence, the same actions are taken for the second up-
date. Di®erent from this, the Log block scheme allocates a
single log block and writes the new data to a free page for
the ¯rst update, then again writes into another free page
of the same log block the second new data, in sequence. If
there is not enough free replacement blocks or log blocks, a
merge operation occurs even though there may still remain
many free pages in both the replacement blocks and the log
block.
For the merge operation, the Replacement block scheme
allocates a clean block and copies valid pages in the old data
block that will be reclaimed to the newly allocated block.
In addition, the valid pages in the replacement blocks are
copied to the new data block. Then, the old data block and
replacement blocks are erased. The merge operation for the
Log block scheme is similar to that of the Replacement block
scheme except for searching all the pages in the log block to
¯nd valid pages. The Log block scheme then, erases the old
data block and the log block.
Figure 2 depicts the distinct actions of the Log block
scheme and the FAST scheme for the same scenario men-
tioned above. As the FAST scheme is an extension of the
Log block scheme, the FAST scheme writes the two update
requests for the LBN 0x08 to a log block just as the Log block
scheme would do. Then, when LBN 0x10 is updated, the Log
block scheme requires another log block for the data block
that contains LBN 0x10 since LBN 0x10 and LBN 0x08 are
not in the same data block. Di®erent from the Log block
scheme, the FAST scheme writes the LBN 0x10 update re-
quest into a single shared log block. When reclaiming a log
block, the Log block scheme needs to erase a data block for
the corresponding log block whereas the FAST scheme may
have to erase several data blocks for the shared log block.
3. ABSORBING HOT WRITE REFERENCES
This study focuses on the e®ect of hot write references and
on the e®ect of the nonvolatile write cache for the hot write
references on the FTL schemes. The hot write references
incurred to support high data integrity can be absorbed by
various forms of nonvolatile write cache. In this section,
we describe the various ways hot write references may be
absorbed, and in particular, the method that is adopted in
our evaluation.
Nonvolatile write caches can come in various forms accord-
ing to the software layer in which the cache is adopted, the
nonvolatile media that the cached data is stored in, and the
method that the cache selects hot write references. Speci¯-
cally, ¯rst, the write cache can be located in the ¯le system
layer [14], the block device driver layer [8], and the FTL
layer [11]. Second, for nonvolatile write caches, there are
various forms of nonvolatile storage media such as Battery-
backed RAM [1] and Nonvolatile RAM (NVRAM). The NVRAM
such as FeRAM (Ferro-electric RAM), PRAM (Phase-change
RAM), and MRAM (Magnetoresistive RAM), which have
recently caught the interest of major semiconductor compa-
nies may also be used as nonvolatile write cache storage [6].
Third, hot write references may be absorbed in various ways.
Many schemes for selecting hot references based on recency,
frequency, and characteristics of ¯le system metadata have
been proposed [7, 8, 9].
In our evaluation, we consider the VFAT ¯le system pro-
vided in Linux as the host ¯le system since various Flash
storages are pre-formatted by the FAT ¯le system, which
is the dominant ¯le system for Flash storage devices. For
high data integrity, we assume that the applications always
write ¯les synchronously. The write cache that we consider
is located in the ¯le system layer and the nonvolatile me-
dia for our write cache is NVRAM, speci¯cally, FeRAM.
As hot write references, we take the write references for ¯le
system metadata such as File Allocation Table (FAT) and
DOS DIR ENTRY. Hence, we modify the VFAT ¯le system
to make use of an NVRAM write cache for its metadata.
4. EXPERIMENTAL ENVIRONMENT
Our experiments are conducted on a real embedded sys-
tem environment. In doing so, we implement the FTL schemes
that we consider in Linux 2.6.21. In this section, we describe
the hardware system that we use in our experiments and
brie°y mention the implementation of the FTLs. We also
introduce the ¯le system workloads that we consider.
4.1 Hardware Setup
For the performance evaluation, the FTL schemes are de-
ployed in a real embedded system development board [2].
The embedded development board has 64MB SDRAM and
64MB NAND Flash memory that consists of 512B data
pages and 16B spare area. The NVRAM daughter board
developed in-house is able to attach a maximum of 64MB of
FeRAM. For the evaluations, the ¯le system always mounts
a 32MB partition of the NAND Flash memory and exploits
just 128KB of FeRAM, which is enough to absorb the whole
¯le system metadata in our con¯guration of benchmarks.
The NVRAM appears in the physical memory address space
and can be directly accessed from the CPU via memory
mapped addressing.
4.2 Software Implementation
For evaluation, we implement the FTL schemes that we
consider in Linux 2.6.21. For the Replacement block scheme,
speci¯cally, we modify the NFTL module included in Linux
2.6.21, that is, an FTL provided only for Flash devices de-
veloped by M-System. Both the Log block scheme and the
FAST scheme are implemented on the MTD (Memory Tech-
nology Device) layer. The Log block scheme and the FAST
scheme is implemented based on the description given in the
paper by Kim et al. and Lee et al., respectively [12, 13]. For
all the experiments we set both the number of log blocks
and the number of replacement blocks to 64.
4.3 File System Workloads
Flash storage is prevalent in a broad range of commod-
ity computing systems from embedded systems to general
purpose computing systems. For our evaluation, we con-
sider two benchmarks, the Camera-MS500 benchmark and
the PostMark benchmark. Each benchmark generates real
life workloads for embedded systems and server systems, re-
spectively.
Camera-MS500: To the best of our knowledge, there is
no de facto realistic ¯le system workload that re°ects the
characteristics of embedded systems. Thus, we develop a
new benchmark program that we call Camera-MS500 that

(a) Write Reference Patterns
(b) Write references from VFAT ¯le system to FTLs
Figure 3: Write reference patterns for the Camera-
MS500 benchmark: before (left graphs) and after
(right graphs) absorbing hot write references.
simulates ¯le system operations for the camera module built
into a popular real world mobile phone¤. By utilizing the
BitPim tool published as a Sourceforge project, we can ob-
serve the changes of the ¯le system after taking pictures and
deleting the pictures [3]. Using this observation, we imple-
ment the Camera-MS500 benchmark program that gener-
ates a realistic ¯le system workload for a digital camera.
The workload that the Camera-MS500 generates consists
of several photo ¯les and a ¯le that is frequently updated
to retain index information such as the creation date and
user descriptions for each photo ¯le. The size of an acyclic
photo index ¯le increases by 96B in proportion to the num-
ber of photo ¯les. When photo ¯les are created or deleted,
this photo index ¯le synchronously creates or deletes index
information for the corresponding photo ¯le.
The benchmark initially has no ¯les. Then, it executes
a speci¯ed number of transactions, in our case, set to 10.
During a transaction, the benchmark generates 20 photo
¯les whose size ranges from 300KB to 500KB and deletes
half of the generated ¯les. If the total number of photo ¯les
is greater than 60, all the photo ¯les are deleted to make
space available. In our con¯guration, the total footprint
that the Camera-MS500 benchmark generates is 79.67MB.
To support high data integrity, we implement it so that each
photo ¯le and photo index ¯le writes synchronously in 512B
units.
PostMark: The PostMark benchmark, which models
workloads of large Internet servers, has been widely used
to evaluate disk based ¯le system performance [10]. In our
evaluation, the PostMark benchmark v1.5 creates ten direc-
tories along with a set of 500 initial ¯les of random sizes rang-
ing from 512B to 32KB. After creating the initial ¯les, the
Postmark benchmark executes a speci¯ed number of trans-
actions, in our case, set to 10,000. For each transaction,
the Postmark benchmark performs a pair of ¯le operations.
That is, it either creates or deletes a ¯le and then appends
to an existing ¯le in 512B units or reads another existing
¤The model number is MS500 developed by Motorola.
(a) Write Reference Patterns
(b) Write references from VFAT ¯le system to FTLs
Figure 4: Write reference patterns for the PostMark
benchmark: before (left graphs) and after (right
graphs) absorbing hot write references.
¯le in its entirety. To remove the bu®ering e®ect in the ap-
plication level, our con¯guration does not make use of the
standard I/O library. The other parameters not mentioned
are set to default values.
In our con¯guration, the total footprint that the Postmark
benchmark generates is 113.29MB. We modify the Postmark
benchmark to update all the ¯le data and metadata syn-
chronously to assure high data integrity.
5. PERFORMANCE EVALUATION
In this study, we are interested in how performance changes
as various FTL schemes are employed when the ¯le system
provides high data integrity to Flash storage. In this section,
¯rst, we discuss the write reference patterns represented by
the workloads that we consider and the write references for
each page that each FTL scheme requests to Flash memory.
Then we discuss the e®ect of hot write references and the
removal of the references via NVRAM on the FTL schemes
in detail.
5.1 Write References Patterns
In Figure 3, we see the write reference pattern generated
by the Camera-MS500 benchmark. Figure 3(a) represents
the (y-axis) the Logical Block Number (LBN) for write refer-
enced blocks as (x-axis) write requests are processed during
the execution of the Camera-MS500 benchmark. Figure 3(b)
shows the number of write requests made for each LBN ob-
served by the FTL. The ¯gures on the left hand side are for
workloads including hot write references, while the ¯gures
on the right hand side are for workloads where the hot write
references are absorbed via NVRAM.
The Camera-MS500 benchmark generates sequential write
references with hot write references for ¯le system metadata,
which is represented in the low numbered sectors. We ob-
serve that 60% of write references are to 0.2 % of the total
LBNs of the Camera-MS500 benchmark. This is shown on
the left graphs of Figure 3(a) and (b). After absorbing the
hot write references via NVRAM write cache, the total num-

(a) Replacement block scheme
(b) Log block scheme
(c) FAST scheme
Figure 5: Write references from FTLs to Flash mem-
ory for the Camera-MS500 benchmark: before (left
graphs) and after (right graphs) absorbing hot write
references for the respective FTL used.
ber of write requests decreases drastically as shown by the
disappearance of the dots along the x-axis for the right side
graph of Figure 3(a) and along the y-axis for the right side
graph of Figure 3(b).
Figure 4 shows write reference patterns for the PostMark
benchmark. From Figure 4, we see that the PostMark bench-
mark writes metadata and ¯le data more intensively than
the Camera-MS500 benchmark. For the PostMark bench-
mark, 56.9% of write references are to 0.3% of the total
LBNs. As a result, similar observations can be made of the
Postmark benchmark as those made for the Camera-MS500
benchmark. Furthermore, although the workload that the
PostMark benchmark generates has both randomness and
sequentiality, the write reference patterns are rather close
to random references when including hot write references.
This randomness can be weakened by absorbing hot write
references.
5.2 Write References by FTLs
The number of write requests made to particular pages in
Flash memory by each FTL before the hot write references
are ¯ltered by the ¯le system NVRAM write cache and af-
ter they are ¯ltered for the Camera-MS500 benchmark are
shown on the left graphs and right graphs of Figure 5, respec-
tively. Generally, all of the FTL schemes tends to scatter
hot write references for speci¯c LBNs around all the pages
in Flash memory. When we compare the left side graphs
with the right side graphs, we observe that the number of
Figure 6: Total execution time measured at the ap-
plication layer for the Camera-MS500 benchmark:
before (referred as Hot) and after (referred as No-
Hot) absorbing hot write references.
Figure 7: Total execution time measured at the ap-
plication layer for the PostMark benchmark: before
(referred as Hot) and after (referred as No-Hot) ab-
sorbing hot write references.
requests to Flash memory is reduced drastically by absorb-
ing hot write references. These observations are also found
in the corresponding results for the PostMark benchmark
even though the graphs are not presented here due to space
limitations. By absorbing hot write references, we observed
that for the Camera-MS500 and the PostMark, respectively,
a total of 60% and 57.4% of the write references are elimi-
nated.
5.3 Effects of Absorbing Hot Write References
In this subsection, we ¯rst discuss the performance com-
parisons of the FTL schemes for the Camera-MS500 and
PostMark benchmarks and then, analyze the performance
variations incurred by absorbing hot write references.
Figure 6 depicts the performance of the FTL schemes for
the Camera-MS500 benchmark in terms of the total execu-
tion time measured at the application layer. Note that the
workloads that we consider contains sequential write pat-
terns with numerous hot write references for the ¯le system
metadata, and the hot write references, that is, ¯le system
metadata writes, can be absorbed via NVRAM write cache.
Let us discuss the performance for each FTL scheme for
the Camera-MS500 benchmark. The Log block scheme out-
performs not only the Replacement block scheme, but also
the FAST scheme for the Camera-MS500 workload that con-
tains hot write references. As expected, the Replacement

block scheme su®ers from hot write references whereas both
the Log block scheme and FAST scheme endure hot write
references well.
Contrary to expectation, the FAST scheme does not per-
form as well as the Log block scheme for this workload. The
reason behind this is that the FAST scheme uses a log block
for all data blocks in Flash memory whereas the Log block
scheme uses a log block for a single data block as mentioned
in Section 2. In so doing, the FAST scheme misses more on
opportunities to switch merge the log block to a data block
on sequential write references as the log block is mixed with
hot write references for other data blocks as well.
For the Camera-MS500 workload, as shown in Figure 6,
when hot write references are absorbed via NVRAM, the
performance improvement varies from 3 to 30 times for the
di®erent FTLs. Speci¯cally, for the Replacement block scheme
the improvement is 30 times, while for the Log block scheme
and the FAST scheme, it is 3.2 times and 6.6 times, respec-
tively. Also from the ¯gure, we see that the performance
di®erence among the FTL schemes become negligible after
absorbing the hot write references.
Though hardly noticeable, we note that the Replacement
block scheme outperforms the Log block scheme after ab-
sorbing hot write references. The reason behind this is that
the advantage of the Log block scheme over the Replace-
ment block scheme becomes minimal as the majority of the
workload becomes sequential after absorbing hot write ref-
erences. Furthermore, due to its simplicity, the overhead
of managing the mapping table for the Replacement block
scheme is minimal leading to better performance in a real
system.
For the PostMark benchmark, the total execution time
measured at the application layer for the three FTLs are
shown in Figure 7. Similar to the results for the Camera-
MS500 benchmark, absorbing hot write references for the
PostMark benchmark not only greatly improve the absolute
execution time, but it also signi¯cantly reduces the perfor-
mance di®erences between the FTL schemes. Speci¯cally,
the FAST scheme shows the best performance among the
FTL schemes regardless of the existence of hot write refer-
ences. This result is natural when considering the random
write reference patterns of the Postmark workload. Note
that the performance of the Log block scheme is the worst
for the PostMark benchmark when all ¯le data writes are
synchronous. This is because, as pointed out by Lee et
al., the Log block scheme cannot e±ciently make use of log
blocks for fully random write references [13]. In particu-
lar, hot write references makes the utilization of log blocks
extremely low so that merge thrashing is triggered. Further-
more, the performance gap between the Replacement block
and Log block schemes is further incurred as the Log block
scheme spends more computational resource to process in-
ternal operations such as the merge operation.
6. SUMMARY AND FUTURE WORKS
In this paper, we considered the e®ect of hot write refer-
ences on the performance of FTL schemes when ¯le systems
ensure high data integrity. We also consider the e®ect of
absorbing these hot write references via NVRAM on the
performance of the FTL schemes in Flash storage.
Through a wide range of evaluations, we observe that the
performance results of the FTL schemes when hot write ref-
erences exist does not conform with results of previous stud-
ies on FTL schemes. We also conclude that the impact of
the underlying FTL schemes on the performance of Flash
storage is dramatically reduced by absorbing the hot write
references via NVRAM.
Though we have presented a wide range of evaluations
for the performance of FTL schemes, the work here is still
preliminary. As mentioned earlier, nonvolatile caches for hot
write references can be deployed in various ways. As future
work, we intend to broaden our study to NVRAM write
cache in the FTL layer and the cache management policy
issues for e±ciently absorbing the hot write references.
7. REFERENCES
[1] Umem NVRAM Cards, http://www.vmetro.com.
[2] EZ-X5 Board, http://www.falinux.com/zproducts.
[3] BitPim Sourceforge Project, http://www.bitpim.org.
[4] A. Ban. Flash ¯le system. United States Patent, No.
5,404,485, 1995.
[5] A. Ban. Flash ¯le system optimized for page-mode
°ash technologies. United States Patent, No. 5,937,425
, 1997.
[6] G. W. Burr, B. N. Kurdi, J. C. Scott, C. H. Lam,
K. Gopalakrishnan, and R. S. Shenoy. Overview of
candidate device technologies for storage-class
memory. IBM Journal of Research and Development,
52(4-5):449{464, 2008.
[7] I. H. Doh, J. Choi, D. Lee, and S. H. Noh. Exploiting
Non-Volatile RAM to Enhance Flash File System
Performance. In Proceedings of the 7th ACM & IEEE
International Conference on Embedded Software, pages
164{173, 2007.
[8] B. S. Gill and D. S. Modha. WOW:Wise Ordering for
Writes . Combining Spatial and Temporal Locality in
Non-Volatile Caches. In Proceedings of the 4th
USENIX Conference on File and Storage
Technologies, pages 129{142, 2005.
[9] J.-W. Hsieh, T.-W. Kuo, and L.-P. Chang. E±cient
Identi¯cation of Hot Data for Flash Memory Storage
Systems. ACM Transactions on Storage, 2(1), 2006.
[10] J. Katcher. PostMark: a New Filesystem Benchmark.
Technical Report TR3022, Network Appliance, 1997.
[11] H. Kim and S. Ahn. BPLRU: A Bu®er Management
Scheme for Improving Random Writes in Flash
Storage. In Proceedings of the 6th USENIX Conference
on File and Storage Technologies, pages 239{252, 2008.
[12] J. Kim, J. M. Kim, S. H. Noh, S. L. Min, and Y. Cho.
A Space-E±cient Flash Translation layer for
CompactFlash Systems. IEEE Transactions on
Consumer Electronic, 48(2):366{375, 2002.
[13] S.-W. Lee, D.-J. Park, T.-S. Chung, D.-H. Lee,
S. Park, and H.-J. Song. A Log Bu®er-Based Flash
Translation Layer Using Fully-Associative Sector
Translation. ACM Transactions on Embedded
Computing Systems, 6(3):18, 2007.
[14] K. Salem and S. AkyÄurek. Management of Partially
Safe Bu®ers. IEEE Transactions on Computers,
44(3):394{407, 1995.
[15] C.-H. Wu and T.-W. Kuo. An Adaptive Two-level
Management for the Flash Translation Layer in
Embedded Systems. In Proceedings of the 2006
IEEE/ACM international conference on
Computer-aided design, pages 601{606, 2006.