FFSMark: a Postmark Extension for Dedicated Flash File Systems

Transcription

1 FFSMark: a Postmark Extension for Dedicated Flash File Systems Pierre Olivier Univ. Bretagne Occidentale UMR6285 Lab-STICC F292 Brest, France pierre.olivier@univ-brest.fr Jalil Boukhobza Univ. Bretagne Occidentale UMR6285 Lab-STICC F292 Brest, France jalil.boukhobza@univ-brest.fr Abstract NAND flash memory is the main secondary storage media in embedded systems. One way to integrate such a memory in today s computer systems is to use dedicated Flash File Systems (FFS). In this context, the use of benchmarking tools is crucial as they allow achieving performance evaluations and comparisons between several file systems or several s of a given file-system. Those benchmarking tools must be used very carefully to allow a pertinent analysis of the results. Unfortunately, many state-of-the-art studies related to FFS use hard disk drive based benchmarks, with no specific flash memory properties analysis. They thus failed in providing an exhaustive understanding of the tested FFS. This paper presents FFSMark, an extension of a the well-established benchmarking tool Postmark. FFSMark targets the Linux operating system, and takes into consideration FFS properties in order to give more accurate benchmark results. FFSMark allows to inject a precise initial state for the flash memory in terms of valid, invalid and free space. The benchmark also allows to configure the operating system page cache, and to gather detailed statistics concerning flash operations and wear leveling. A brief case study on FFSMark is presented. It compares, YAFFS2, and UBIFS, the most popular FFS. Experiments showed that contrary to many state-of-theart performance comparisons, there is matter to question about which FFS to use and UBIFS is not always the best deal. I. INTRODUCTION Flash memory is widely used in today s computer systems. As flash-based Solid State Drives (SSD) are more and more competing with hard drives in personal computer systems and high performance computing, NAND flash memory has been the main storage media in embedded systems for some time now. Indeed, such a memory offers many benefits in terms of shock resistance, low power consumption, and good I/O performance. Nevertheless, NAND flash exhibits specific constraints, in particular (1) the impossibility to perform inplace data updates and (2) the fact that memory cells wear out with increasing write / erase cycles. Constraints management mechanisms are integrated in flash-based storage systems, to cope with flash specificities. In the embedded systems domain, dedicated Flash File Systems (FFS) are a widely used flash management mechanism. The most popular FFS are [1], YAFFS2 [2] and UBIFS [3]. They are all integrated in Linux, one of the most used embedded OS [4]. Benchmark programs are widely used in the file-systems domain for measuring and comparing performance, understanding their operating modes, or validating new file-systems or optimizations techniques. A large amount of today s filesystem benchmarks assume a hard drive as the secondary storage media of the benchmarked system. Those benchmarks are used extensively in evaluating FFS performance [5], [6], [7], [8], [9]. In this paper we show that a benchmark targeting FFS must take into account the specificities of the flash storage media (out-of-place data updates, and wear out) in order to give pertinent and exhaustive performance results. Otherwise, one can ignore many realistic scenarios for which important performance glitches can happen. In fact, up to 14% performance drop has been noted on YAFFS2 according to flash system initial state. To answer this question, we propose FFSMark, an extension of Postmark designed for measuring FFS performance with Linux and that takes into account flash specific constraints. FFSMark allows a precise definition of the initial state of the flash memory to test in terms of: valid, invalid and free space. It also allows to capture precise statistics on the wear out and wear leveling, which is extremely important for flash memory. FFSMark also fixes some Postmark known issues such as timing granularity, page cache, etc. In order to support our statements, we also present a case study giving results obtained from running FFSMark on an embedded platform. The results of this case study show the importance of taking into account flash specificities. This paper is organized as follows: in a first section we introduce general notions concerning NAND flash and its management with FFS and Linux. In the next section we present some related works in the FFS benchmarking domain. The FFSMark benchmark is depicted in the third section, and a case study is given in the fourth section. Finally, we give a conclusion. II. NAND FLASH MEMORY AND ITS MANAGEMENT WITH LINUX A. NAND Flash Memory Basics There are several flash memory types. In this paper we are interested in NAND flash memory, which is dedicated to data storage. A NAND flash memory chip exhibits a hierarchical architecture: a chip contains one or more planes. Each plane contains a given number of blocks, and each block contains pages. The page size in flash chips is 2, 4 or 8 KB. Generally, the number of pages per block is 64 or 128 [1]. A chip supports three main operations, namely read, write and erase. The read and write operations are achieved on a page, whereas

2 Userspace Kernel space Software Hardware the erase operation is performed on a whole block. Latencies vary between flash chip models, exemples are 25 µs for a page read, 22 µs for a page write, and 5 µs for a block erase operation [11]. Userspace program Userspace program C Library... B. Operating Constraints and their Management Using flash memory in computer systems implies coping with constraints specific to this type of memory. One of the main constraints is the erase-before-write rule: one cannot write in a page that already contains data. The block containing the page must first be erased. A second constraint is the fact that a flash block can only sustain a limited number of erase operations. After a given threshold is reached, the block can no longer contain data. Because of these constraints, constraints management mechanisms are implemented in flash-based storage systems. They implement several concepts. First, the erasebefore-write rule is managed through the implementation of an address translation system, translating logical addresses (from the OS) to physical ones (in flash memory). It allows writing data corresponding to an updated page into another (free) page. This process is called out-of-place data update. Pages containing old data versions are not directly erased, but marked as invalid. The erase operation is performed later, during the execution of a process called the Garbage Collector (GC), recycling invalid flash space into free space. Generally, the GC works as follows: one or more victim blocks containing invalid pages are selected. Potential still valid pages contained in those blocks are copied into free pages in some other blocks, then the victim block(s) is/are erased. The memory wear is managed through the implementation of wear leveling policies, balancing the write and erase cycles over the whole flash memory array in order to maximize the flash chip lifetime. There are two main classes of flash management systems. The Flash Translation Layer (FTL) is a hardware / software solution implemented in the controller of some flashbased storage peripherals such as USB flash drives, SSD, SD/MMC cards, emmc, etc. A second solution is to use dedicated Flash File Systems (FFS). It is a purely software solution, implemented in the embedded OS implemented in smartphones, tablets, set-top boxes, gateways, etc. These FFS generally manage embedded flash chips. In this paper we are only interested in FFS. In this context, we will consider Linux which is one of the main embedded OS that supports the most popular FFS. C. Linux and Dedicated Flash File Systems FFS storage with Linux can be seen as a stack, presented on Figure 1. On the top of this stack are the user space programs, accessing files through system calls: open, read, write, etc. These system calls are received by the Virtual File System (VFS), which is an abstraction layer for all the file systems supported by Linux. VFS forwards I/O operations to the concerned file system, in our case a FFS. Finally, the FFS uses the NAND driver to perform flash operations on the NAND flash chip. With Linux, all supported flash chips are accessed with a generic driver named Memory Technology Device (MTD). At the VFS level, the page cache is a data cache buffering all data accessed by user pace programs. The page cache potentially uses all the RAM that is not used by programs. Fig. 1. System calls (open, read, write, etc.) FFS : Virtual File System (VFS) FFS : UBIFS UBI NAND driver : Memory Technology Device (MTD) NAND flash chip Linux embedded flash management stack. Today, there are three main FFS are [1], YAFFS2 [2] and UBIFS [3]. (the Journaling Flash File System version 2) is natively integrated in the kernel since 21 (Linux 2.4.1), and consequently is very mature. YAFFS2 (Yet Another Flash File System) also dates back to 21, and can be integrated in the kernel through a patch. Finally, UBIFS (the Unsorted Block Image File System) is the most recent FFS, present in the kernel mainline since 28 (Linux ). For reasons of space, in this paper we do not give a detailed description of those FFS implementations. Nevertheless, it is important to highlight some major distinctions between them. First, as UBIFS is the latest FFS, it was built by enhancing some of and YAFFS2 limitations. In particular, UBIFS uses trees as indexing structures for the managed files, whereas and YAFFS2 use tables. Thus, UBIFS RAM footprint and mount time increase logarithmically with the amount of flash space managed (the partition size). This increase is linear with and YAFFS2, making them unusable on large flash partitions [3]. Moreover, UBIFS supports the Linux page cache write back functionality, thus taking full benefit from the temporal locality of file accesses to enhance performances. On the contrary, and YAFFS2 writes are always synchronous. Finally, UBIFS and support on the fly data compression / decompression during file read and write operations. YAFFS2 does not support compression. III. RELATED WORKS: FILE SYSTEM BENCHMARKING AND FLASH MEMORY In the file systems domain, benchmarks are series of tests used to measure various performance metrics. They are useful to compare systems, but also to understand file systems behaviors, or evaluate the performance gain obtained after applying some optimizations. There are three main types of file systems benchmarks [12]. Macro-benchmarks apply an I/O workload considered to be representative of a given applicative context. Microbenchmarks concentrate on a small set of operations (one or two) applied to the file system, in order to precisely inspect their performance properties. Finally, trace replaying allows to replay on a storage system an I/O workload previously recorded on another system....

3 In the FFS domain, benchmarks are in general used to compare different FFS performance [5], [6], [7], [8], [9]. Some studies present comparisons of existing FFS performance. Moreover, other works propose some new FFS or an optimization of an existing system, and compare their proposition to existing FFS. Most studies use ad-hoc micro-benchmark, i.e. micro-benchmark developped explicitely for the needs of the study. Indeed, to the best of our knowledge, there is no existing standard storage macro-benchmark for the embedded systems domain. In some way, the Postmark [13] macro-benchmark is an exception: although the I/O workload produced by Postmark (the workload of a mail server) is not representative of an embedded application, this benchmark is widely used in the FFS performance evaluation domain [5], [6], [7], [8]. The strong presence of Postmark in the embedded domain is due, on one hand, to its high popularity in general, and on the other hand to the simplicity of the produced I/O workloads (described in the next section). Although these workloads are not really representative of an embedded application, they were considered as sufficiently generic to offer relevant performance indicators for a given FFS and compare several FFS performance. One can note that most of existing file systems benchmarks assume a hard drive to be the secondary storage media of the benchmarked system [12]. Uflip [14] is a benchmark targeting flash memory storage systems. Nevertheless, it is designed to evaluate FTL system performances and not file systems. To the best of our knowledge, there is no file system benchmark considering flash memory as the secondary storage media. It is shown in the preceding section that NAND flash exhibits some specific constraints. Several studies have shown the strong impact of the initial state, defined as the ratio of free / valid / invalid flash space, on a performance evaluation results [15], [16]. Indeed, the presence of invalid data at the start of the benchmark triggers the execution of the Garbage Collector (GC) during the tests. It thus disturbs the benchmark I/O and impacts the performance results. On the other hands, the presence of valid data leads to recopies of still valid data during GC execution. Those additional flash operations realized during the benchmark may once again impact performance results. Moreover, in the FFS domain, it is crucial to take into account the fact that flash wears out according to the number of write / erase cycles. It is thus necessary to add the wear leveling metrics to the classical performance evaluation metrics available from the benchmark. IV. A. Postmark FFSMARK: A DEDICATED FLASH FILE SYSTEM BENCHMARK FFSMark is an extension of Postmark [13]. Postmark was chosen because it is used in numerous studies concerning FFS benchmarking [5], [6], [7], [8]. Moreover, Postmark implementation is relatively simple, and can thus be easily modified. A run of Postmark consists in the execution of several phases. First, during the creation phase, a given number of file containing random data are created, possibly distributed among several subdirectories. The second phase is the transactions phase, in which a given number of transactions are executed. A transaction consists in two sub-phases: (A) reading an existing file or writing some random data in the end of an existing file (append operation) ; then (B) creating a new file or deleting an existing file. After the transaction phase, the remaining files are deleted. Postmark is launched with several parameters: the number of initially created files, their sizes, the number of transactions, the probability to choose a read operation rather than a write operation during the transaction sub-phase (A), etc. Postmark produces as output several statistics concerning the performance of the benchmarked system: the total execution time, the execution time of each phase, the read / write throughputs, etc. B. FFSMark FFSMark s objetive is to adapt Postmark to answer the limitations presented in section III: a benchmark targeting FFS must take into account (1) the initial state in terms of quantity of valid / invalid / free flash space, and (2) the FFS wear leveling. FFSMark extends version 1.5 of Postmark, and is developed in C language. 1) Initial state management: FFSmark allows to define the quantity of free, valid and invalid flash space on the tested flash partition before the creation phase. To do so, FFSMark creates on the tested partition a file containing random data, which is left as is during the benchmark execution. The size of this file represents as much valid data in flash memory. Another file containing random data is created. This second file is deleted (through the remove() system call) just before the creation phase execution. The file deletion causes the invalidation of the file data at the FFS level, and thus allows to define a ratio of invalid data on flash memory. FFSMark takes as input the sizes for these two files, according to the ratio of free space in the tested partition when the benchmark is launched. This permits to control the initial state, and to take into account this important factor impacting the results of a performance evaluation on flash memory. The presence of invalid data triggers the launch of the GC during the benchmark execution, impacting the performance results. Of course, for an optimal control over the quantity of valid / invalid flash space, the benchmark should be ran on a fully erased flash partition. By doing so, one is assured that all the flash space that is not dedicated to the valid and invalid files is actually free. 2) Statistics on flash accesses and wear leveling: FFSMark can be jointly ran with Flashmon [17], which is a Linux kernel module allowing to trace flash operations at the driver level: flash pages read and writes, and blocks erasures. It was shown using measurements that Flashmon impact on flash I/O performance is negligible (lower than 5%) [17]. FFSMark communicates with Flashmon and outputs statistics concerning flash accesses: the number of flash page read and write operations, the number of block erase operations, the mean number of erasures per block, the standard deviation of the block erase counters distribution, and the difference in terms of number of erasures between the most erased and the less erased block of the tested partition. Statistics concerning erase operations allow to estimate the quality of the wear leveling performed by the benchmarked FFS.

4 3) Other Postmark enhancements: In [12], authors note some limitations concerning Postmark. In particular, the time measurements realized by the benchmark are rather imprecise. Indeed, Postmark uses the time() system call. FFSMark uses the gettimeofday() Linux system call, giving a microsecond precision. Moreover, FFSMark gives the possibility to empty the page cache (1) before the creation phase and, more importantly, (2) before the transactions phase. As a matter of fact, Postmark creation phase can be seen as the setup of an initial state for the system, and the transaction phase can be seen as a steady state of I/O request generation. Thus, it is normal to empty the system caches between these two phases. V. CASE STUDY In this section we present a case study for FFSMark. We compare the performance of the three main FFS,, YAFFS2 and UBIFS, on the Armadeus APF27 [18] embedded development board. The objective of this part is not to perform an exhaustive experimentations on the previously given parameters, but rather highlight the impact of parameters that are considered by FFSMark. A. Methodology We define two FFSMark s. These s differ only in the initial state given by FFSMark to the flash memory. With the named free file system, we launch the benchmark on a completely free flash partition : the partition is fully erased before each benchmark launch. The other, named aged file system, defines an initial state with 5% of valid flash space, and 25% of invalid space. These values are chosen to observe the performance gap due to the initial state. The size of the test partition is 1 MB. The other parameters of FFSMark are the same for both s. They are defined to generate an I/O workload adequately to stress the benchmarked file systems. Concerning the parameters introduced by FFSMark (with respect to Postmark), the page cache is emptied before the creation phase, and before the transactions phase. The extraction of statistics on flash accesses and wear leveling through Flashmon is activated. Table I presents the values of all the parameters for both s. The two s are launched with, YAFFS2 and UBIFS, executed with Linux on the Armadeus APF27 embedded board. This board contains a Freescale i.mx27 CPU with an ARM9 core clocked at 4 MHz, and 128 MB of RAM. The board also embeds 256 MB of Micron NAND flash memory with 2 KB pages and 64 pages per block [11]. Before each of the FFSMark launches, the flash test partition is fully erased an a new file system is created. UBIFS and both support on the fly data compression. For those FFS, each is launched with the compression enabled, and with compression disabled. UBIFS is the only FFS supporting the page cache write back feature, so for this FFS each is launched with the write back enabled, and with the write back disabled. Write-back is disabled by mounting UBIFS with the sync mount flag. Execution time (s) Parameter Value Parameters inherited from Postmark Number of created files 5 Number of subdirectories 5 Sizes of created files (bytes) random between 512 and 124 Number of transactions 15 Size for reads / writes (bytes) 496 Probability to have a read rather than a write 5 operation in transactions sub-phase (A) (%) Probability to have a creation rather than a 5 deletion in transactions sub-phase (B) (%) Read and write functions read(), write() FFSMark specific parameters Statistics on flash accesses through Flashmon Yes Page cache emptied before creation phase Yes Page cache emptied before transactions phase Yes Valid flash space before creation phase (% of free conf.:, the tested partition) aged conf.: 5 Invalid flash space before creation phase (% free conf.:, of the tested partition) aged conf.: 25 TABLE I. PARAMETERS FOR BOTH FFSMARK CONFIGURATIONS Number of block erase operations Free YAFFS2 UBIFS Transactions phase Creation phase Aged 1631 YAFFS2 UBIFS 14 Free Aged YAFFS2 UBIFS Fig. 2. Initial state impact: execution times for the two FFSMark phases (top left and right) and wear leveling (bottom) when varying the initial state. The number present in each bar of the bottom sub figure is the difference between the most erased block erase counter, and the less erased block erase counter. Some bars related to YAFFS2 are cut off from the figures for the sake of clarity, in that case Y values are written in text. B. Results 1) Initial State Impact: Barcharts on the top left and top right of Figure 2 show the execution times for both FFSMark phases (creation and transactions) when varying the tested FFS and the initial state: free or aged. The bottom barchart on that same Figure 2 depicts the number of block erasures observed during the benchmark, and the difference in block erase counters between the most and the less erased blocks. For these tests, compression is disabled for and UBIFS, and write back is enabled for UBIFS. A first important observation is the strong increase in 2 5

5 Write throughput (Kb/s) Free Aged UBIFS (Write-back on) UBIFS (Write-back off) Write throughput (Kb/s) Compression enabled Compression disabled UBIFS Number of block erase operations Free Aged UBIFS (Write-back on) UBIFS (Write-back off) Number of flash page writes UBIFS Fig. 3. Disabling write back support of UBIFS: Write throughputs (top) and wear leveling (bottom) for and UBIFS with write back enabled / disabled. Fig. 4. Compression impact: Write throughputs (top) and number of flash write operations (bottom) for and UBIFS, with compression enabled and disabled. execution times on the aged, as compared to the free one. This is partcularly true for the execution time of the transactions phase: we can observe for that phase an increase of 95% for UBIFS, 34% for and more than 14% for YAFFS2, which seems to behave especially bad on the aged. These results show the importance of the initial state of a flash-based storage system during performance evaluation (benchmarking, among other things) on flash memory. In fact, according to the application domain, one might need the best performing system or the more stable / predictable one. proved a better stability while UBIFS the best average performance. Although the performance difference according to the for UBIFS is larger as compared to, the execution times are better for UBIFS. On a free, UBIFS execution times are much lower than and YAFFS2 execution times. This is due to the write back support by UBIFS, allowing this FFS to benefit from the temporal locality of write operations. The difference between the two s in term of number of erase operations observed during each test shows that the GC is indeed responsible of the performance drop on the aged : There are 329% more erasures with UBIFS, 122% with, and 14% with YAFFS2. Concerning the difference between erase counters, we can see that regardless of the inital state, the wear leveling is better with (free: 1 ; aged: 3), closely followed by UBIFS (2 ; 8). YAFFS2 (5, 14) which seems once again to perform relatively badly, in particular on the aged. 2) UBIFS and Synchronous Writes: Performing synchronous (non buffered) writes can be necessary in certain circumstances: for example, one can think of the risk of buffered data loss in some battery backed embedded systems. Another example might be the need for determinism in access times in some real-time applications. We launched FFSMark when disabling write back support for UBIFS, the only FFS supporting this feature. Results are presented on Figure 3. In these tests the compression is disabled. Concerning write throughputs and wear leveling, UBIFS gives better performance than when the write back is enabled. Nevertheless, when this feature is disabled, becomes better than UBIFS. This is especially true on the aged, under which offers a write throughput more than two times better than UBIFS throughput, and generates 5 times less erase operations. Interestingly, several studies agree that UBIFS is fully superior to [9], [19]. FFSMark shows that under certain conditions, offers better performance and a better wear leveling that UBIFS in synchronous write mode. UBIFS performance drop in synchronous write mode is due to the indexing structure management performed by that FFS. UBIFS uses a tree which nodes are written on flash. Each update to the file system causes an update of a node in the indexing tree. As in-place data updates are not possible on flash memory, on synchronous write mode each node parent of the updated node must itself be updated and rewritten on flash, up to the tree root [3]. When performing asynchronous writes (write back enabled), file updates are absorbed in the page cache an flushed in large chunks on flash memory, strongly reducing the indexing tree updates overheads. 3) Compression Impact: We launched FFSMark with data compression enabled then disabled, this feature is available on and UBIFS. Results are presented on Figure 4. The results are only given for the free. One can see that enabling compression leads to a performance drop: the write throughput decreases by a factor 2.5 for, and 1.3 for UBIFS. Nevertheless, concerning the number of flash page write operations observed during the benchmark, one can see a small decrease for both FFS when compression is enabled. The files accessed by FFSMark contain random data, which is hardly compressible. Thus, the FFS wastes some time by trying to compress incompressible data, leading to the performance drop. Such an observation has already been

6 made in [2], where the authors propose, for, a system of selective compression based on the type of file accessed. Concerning read throughput and execution times, not presented here, they follow the same behavior as the write throughput. In fact, beyond those conclusions, variability of performance (on execution times or wear leveling) is very important and need to be studied to well characterize and understand the execution of a given application on a chosen FFS. 4) Discussion about the Generalization for FTL Based Systems: In this paper we proposed and implemented an extension of the Postmark benchmark tool for flash based storage systems. We focused on FFS which is one of the two main classes of flash integration. The other one, FTL systems, is the most common and widely adopted flash memory integration mechanism. For FTL based systems, as the flash specific intricacies are abstracted to the file-system (and the operating system in general), statistics cannot be retrieved with Flashmon-like module. However, the concepts about initial state definition can be ported or used as is with Postmark. In fact, initial state definition should be used wherever flash memory is evaluated, but is unfortunately missing in many state-of-the-art work. For instance, most of flash memory simulators do not provide means allowing to define the initial state of the flash memory before simulation. With respect to this issue, we think that there is room for flash system simulator investigations in the context of initial state definition. Beyond the initial state issue, in flash-based storage system, even though it is agreed that performance and wear out are very important issues, however the robustness of the management mechanisms is still poorly studied. For both state-of-the-art FTLs and FFS, many parameters can be varied to tune the management layer according to the applied workload, but it seems very important to characterize the behavior of the different s according to the whole environment (workload flash memory, caches...). And a prior work to this study consists in determining the most important parameters/metrics to take into account. This was partially the objective in developing FFSMark that is a yet simple, but very useful tool to use in characterizing FFS based systems. VI. CONCLUSION In this paper we present FFSMark, a benchmark targeting dedicated Flash File Systems used with Linux. Based on the popular Postmark, FFSMark takes into consideration NAND flash specificities - (1) the erase-before-write rule infering outof-place updates and valid/invalid data states and (2) cells wear out on write / erase cycles. FFSMark allows to specify an initial state for the benchmark, in terms of ratio of valid, invalid and free flash space. FFSMark also outputs useful flash statistics, in addition to standard performance metrics. Flash statistics include in particular information about the wear leveling realized during the benchmark execution. We also present a case study of FFSMark execution on an embedded platform, comparing, YAFFS2 and UBIFS performance on some relevant parameters variation.this case study highlights some previously unobserved behavior, in particular concerning the performance difference between UBIFS in synchronous write mode and, on an aged file system. FFSMark sources are available at the following address: pierre/?page id=29. REFERENCES [1] D. Woodhouse, : the journalling flash file system version 2, in Ottawa Linux Symposium, Ottawa, Canada, 21. [2] Wookey, YAFFS - a NAND flash file system, in CE Linux Conference, Linz, Autriche, 27. [Online]. Available: yaffscelf27.pdf [3] A. Hunter, A brief introduction to the design of UBIFS, 28, http: // whitepaper.pdf. [4] UBM Tech, Embedded market study, 213, content.ubmtechelectronics.com/web/ubmtechelectronics/ %7Ba7a91fe-87c-4a6d-b861-d414777f831%7D 213EmbeddedMarketStudyb.pdf. [5] J. Kim, H. Shim, S. Park, S. Maeng, and J. Kim, FlashLight: a lightweight flash file system for embedded systems, ACM Trans. Embed. Comput. Syst., vol. 11S, no. 1, p. 18:1 18:23, Jun [6] S. Lim and K. Park, An efficient NAND flash file system for flash memory storage, Computers, IEEE Transactions on, vol. 55, no. 7, p , 26. [7] S. Liu, X. Guan, D. Tong, and X. Cheng, Analysis and comparison of NAND flash specific file systems, Chinese Journal of Electronics, vol. 19, no. 3, 21. [8] Y. Kang and E. L. Miller, Adding aggressive error correction to a high-performance compressing flash file system, in Proceedings of the Seventh ACM International Conference on Embedded Software, ser. EMSOFT 9. New York, NY, USA: ACM, 29, p [9] M. Opdenacker, Update on filesystems for flash storage, Ede, Netherlands, 28. [1] L. M. Grupp, A. M. Caulfield, J. Coburn, S. Swanson, E. Yaakobi, P. H. Siegel, and J. K. Wolf, Characterizing flash memory: anomalies, observations, and applications, in Microarchitecture, 29. MICRO nd Annual IEEE/ACM International Symposium on. IEEE, 29, p [11] Micron Inc., MT29F2G16ABDHC-ET:D NAND flash memory datasheet, 27. [Online]. Available: 2Inc%2PDFs/MT29F2G(8,16)AAD,ABD.pdf [12] A. Traeger, E. Zadok, N. Joukov, and C. P. Wright, A nine year study of file system and storage benchmarking, ACM Transactions on Storage (TOS), vol. 4, no. 2, p. 5, 28. [13] J. Katcher, Postmark: A new file system benchmark, Technical Report TR322, Network Appliance, Tech. Rep., [Online]. Available: Katcher97-postmark-netapp-tr322.pdf [14] M. Bjørling, P. Bonnet, L. Bouganim, B. Jónsson et al., uflip: understanding the energy consumption of flash devices, IEEE Data Engineering Bulletin, vol. 33, no. 4, p , 21. [15] M. Bjørling, L. Le Folgoc, A. Mseddi, P. Bonnet, L. Bouganim, and B. Jónsson, Performing sound flash device measurements: some lessons from uflip, in Proceedings of the 21 ACM SIGMOD International Conference on Management of data. ACM, 21, p [16] P. Olivier, J. Boukhobza, and E. Senn, Micro-benchmarking flash memory File-System wear leveling and garbage collection: A focus on initial state impact, in Proceedings of the 212 IEEE 15th International Conference on Computational Science and Engineering, ser. CSE 12. Washington, DC, USA: IEEE Computer Society, 212, p [17], Flashmon v2: Monitoring raw NAND flash memory I/O requests on embedded linux, ACM SIGBED Rev., vol. 11, no. 1, p , 214. [18] Armadeus Wiki - APF27 board, 215, wiki/index.php?title=apf27. [19] T. Homma, Evaluation of flash file systems for large NAND flash memory, in CELF Embedded Linux Conference, San Francisco, Etats Unis, 29. [Online]. Available: ELC29-FlashFS-Toshiba.pdf [2] H. Song, S. Choi, H. Cha, and R. Ha, Improving energy efficiency for flash memory based embedded applications, Journal of Systems Architecture, vol. 55, no. 1, pp , Jan. 29.