DOCSLIB.ORG

Non-Volatile Memory File Systems: a Survey

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Non-Volatile Memory File Systems: a Survey Received December 18, 2018, accepted January 8, 2019, date of publication February 14, 2019, date of current version March 8, 2019. Digital Object Identifier 10.1109/ACCESS.2019.2899463 Non-Volatile Memory File Systems: A Survey GIANLUCCA O. PUGLIA 1, AVELINO FRANCISCO ZORZO1, (Member, IEEE), CÉSAR A. F. DE ROSE1, (Member, IEEE), TACIANO D. PEREZ1, AND DEJAN MILOJICIC 2, (Fellow, IEEE) 1Pontifical Catholic University of Rio Grande do Sul, Faculty of Informatics -FACIN, Porto Alegre 90619-900, Brazil 2Hewlett-Packard Labs, Palo Alto, CA 94304-1126, USA Corresponding author: Avelino Francisco Zorzo ([email protected]) This work was supported in part by the Coordenação de Aperfeiçoamento de Pessoal de Nivel Superior–Brazil (CAPES) under Finance Code 001, and in part by the Hewlett Packard Enterprise (HPE) with resources under Law 8.248/91. ABSTRACT For decades, computer architectures have treated memory and storage as separate entities. Nowadays, we watch the emergence of new memory technologies that promise to significantly change the landscape of memory systems. Byte-addressable non-volatile memory (NVM) technologies are expected to offer access latency close to that of dynamic random access memory and capacity suited for storage, resulting in storage-class memory. However, they also present some limitations, such as limited endurance and asymmetric read and write latency. Furthermore, adjusting the current hardware and software architectures to embrace these new memories in all their potential is proving to be a challenge in itself. In this paper, recent studies are analyzed to map the state-of-the-art of NVM file systems research. To achieve this goal, over 100 studies related to NVM systems were selected, analyzed, and categorized according to their topics and contributions. From the information extracted from these papers, we derive the main concerns and challenges currently being studied and discussed in the academia and industry, as well as the trends and solutions being proposed to address them. INDEX TERMS Algorithms, design, reliability, non-volatile memory, storage-class memory, persistent memory. I. INTRODUCTION Therefore, working with data storage in NVM may take The increasing disparity between processor and memory per- the advantage of using different approaches and methods formances led to the proposal of many methods to mitigate that systems designed to work with HDDs do not sup- memory and storage bottlenecks [6], [107]. Recent research port. Moreover, since the advent of NAND flash memo- advances in Non-Volatile Memory (NVM) technologies may ries, the use of NVM as a single layer of memory, merging lead to a revision of the entire memory hierarchy, dras- today's concepts of main memory and back storage, has been tically changing computer architecture as we know today, proposed [98], [99], aiming to replace the whole memory to, for example, a radical memory-centric architecture [38]. hierarchy as we know. Such change in the computer archi- NVMs provide performance speeds comparable to those of tecture would certainly represent a huge shift on software today's DRAM (Dynamic Random Access Memory) and, development as well, since most applications and operating like DRAM, may be accessed randomly with little perfor- systems are designed to store persistent data in the form of mance penalties. Unlike DRAM, however, NVMs are persis- files in a secondary memory and to swap this data between tent, which means they do not lose data across power cycles. layers of faster but volatile memories. In summary, NVM technologies combine the advantages Even though all systems running in such an architecture of both memory (DRAM) and storage (HDDs - Hard Disk would inevitably benefit from migrating from disk to NVM, Drives, SSDs - Solid State Drives). one of the first places one might look at, when considering These NVMs, of course, present many characteris- this hardware improvement, would be the file system. The file tics that make them substantially different from HDDs. system is responsible for organizing data in the storage device (in the form of files) and retrieving this data whenever the The associate editor coordinating the review of this manuscript and system needs it. File systems are usually tailored for a specific approving it for publication was Geng-Ming Jiang. storage device or for a specific purpose. For instance, an HDD 2169-3536 2019 IEEE. Translations and content mining are permitted for academic research only. 25836 Personal use is also permitted, but republication/redistribution requires IEEE permission. VOLUME 7, 2019 See http://www.ieee.org/publications_standards/publications/rights/index.html for more information. G. O. Puglia et al.: NVM File Systems: A Survey file system, like Ext4, usually tries to maintain the data blocks and categorize: problems related to NVM storage, what solu- belonging to a file contiguously or at least physically close to tions to those problems have been proposed, which of those each other for performance reasons. A file system designed problems are still unresolved, what are the new approaches to for flash memory devices, like JFFS2, might avoid rewrit- work with NVMs and how these approaches may improve the ing data in the same blocks repeatedly, since flash memory use of NVMs. Our purpose is to gather and analyze studies blocks have limited endurance. The list could go on, but we related to the application of NVM technologies to different can conclude that whenever the storage hardware changes, types of systems (focused on storage systems) not only to the way data is stored and accessed must be reviewed. In all document them but also to provide a straight-forward guide these cases, file systems should be adapted to this condition for researchers unfamiliar with these concepts. Since most in order to reduce complexity and to achieve the best possible of the promising NVM technologies are still currently under performance. development and access to these technologies is very lim- Concerned with the adaptation of current architectures to ited, this paper expects to deal with more theoretical content NVM devices, in the 2013 Linux Foundation Collaboration rather than experimental results and technical applications Summit [26], the session ``Preparing Linux for nonvolatile (although those are important to the area). memory devices'' proposed a three-step approach to migrate Complementary to our study, a survey presented by Mit- today's systems to a fully NVM-aware model. In the first step, tal and Vetter [94] provides an overview of NVM tech- file systems will access NVM devices using NVM-aware nologies and reviews studies focused on either combin- block drivers under traditional storage APIs and file systems. ing or comparing different memory technologies. Even This step does not explore the disruptive potential of NVM though the previous survey presents a classification of but is a simple method for making it quickly deployed and NVM-related solutions, it does not discuss future directions accessible by today's systems. nor features that deserve additional investigation. Another In the second step, existing file systems will be adapted study by Wu et al. [133] explores the challenges of adopting to access NVM directly, in a more efficient way. This step Phase-Change RAM (PCM) as storage, main memory or ensures that file systems are designed with NVM charac- both, summarizing existing solutions and classifying them. teristics in mind, but keeping the traditional block-based The remaining of this paper is organized as follows. file system abstraction for compatibility purposes. Signifi- SectionII presents some basic concepts of NVM storage and cant changes in this step may include improvements such as technologies approached in this study. Section III details the directly mapping files into application's address space, fine process used in this systematic mapping study and explains tuning consistency and reliability mechanisms, such as jour- the analysis and classification of the selected studies. Sec- naling, for improved performance and eliminating processing tions IV and V present an extensive discussion about the anal- overhead related to hard disks hardware characteristics. ysis results. In order to broaden the contribution of this paper, The final step is the creation of byte-level I/O APIs to be Section VI discusses some of the work being conducted in used by new applications. This step will explore interfaces industry. Section VII discusses the state of the art and future beyond the file system abstraction that may be enabled by directions. Section VIII presents relevant published related NVM. It has the most disruptive potential, but may break work. Finally, Section IX concludes this paper by providing backward compatibility. It also presents a much higher level a quick overview of the state of the art of NVM file systems. of complexity and the requirements for such ground breaking changes are still being studied. However, at this point, appli- II. BASIC CONCEPTS cations will not only be able to take the best performance out This section presents some concepts that are essential to of NVM, but will also have access to newly improved APIs the NVM storage theme. These concepts are all intimately and persistence models. connected to each other and are also the base knowledge that With this in mind, we aim to provide, with this paper, supports the idea of NVM file systems. Further details on how a much needed detailed overview of the state of the art of these topics work together in practice will be detailed in the NVM-related studies, identifying trends and future directions coming sections. for storage solutions, such as file systems, databases and object stores. The intention is to provide a comprehensive A. NON-VOLATILE MEMORY TECHNOLOGIES view of the area as well as to identify new research and The term Non-Volatile Memory (NVM) may be used to development opportunities. The systematic mapping model address any memory device capable of retaining state in was chosen as a method to reduce research bias and allow the absence of energy.
Load more

Recommended publications
  • Copy on Write Based File Systems Performance Analysis and Implementation
    Copy On Write Based File Systems Performance Analysis And Implementation Sakis Kasampalis Kongens Lyngby 2010 IMM-MSC-2010-63 Technical University of Denmark Department Of Informatics Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 [email protected] www.imm.dtu.dk Abstract In this work I am focusing on Copy On Write based file systems. Copy On Write is used on modern file systems for providing (1) metadata and data consistency using transactional semantics, (2) cheap and instant backups using snapshots and clones. This thesis is divided into two main parts. The first part focuses on the design and performance of Copy On Write based file systems. Recent efforts aiming at creating a Copy On Write based file system are ZFS, Btrfs, ext3cow, Hammer, and LLFS. My work focuses only on ZFS and Btrfs, since they support the most advanced features. The main goals of ZFS and Btrfs are to offer a scalable, fault tolerant, and easy to administrate file system. I evaluate the performance and scalability of ZFS and Btrfs. The evaluation includes studying their design and testing their performance and scalability against a set of recommended file system benchmarks. Most computers are already based on multi-core and multiple processor architec- tures. Because of that, the need for using concurrent programming models has increased. Transactions can be very helpful for supporting concurrent program- ming models, which ensure that system updates are consistent. Unfortunately, the majority of operating systems and file systems either do not support trans- actions at all, or they simply do not expose them to the users.
    [Show full text]
  • The Page Cache Today’S Lecture RCU File System Networking(Kernel Level Syncmem
    2/21/20 COMP 790: OS Implementation COMP 790: OS Implementation Logical Diagram Binary Memory Threads Formats Allocators User System Calls Kernel The Page Cache Today’s Lecture RCU File System Networking(kernel level Syncmem. Don Porter management) Memory Device CPU Management Drivers Scheduler Hardware Interrupts Disk Net Consistency 1 2 1 2 COMP 790: OS Implementation COMP 790: OS Implementation Recap of previous lectures Background • Page tables: translate virtual addresses to physical • Lab2: Track physical pages with an array of PageInfo addresses structs • VM Areas (Linux): track what should be mapped at in – Contains reference counts the virtual address space of a process – Free list layered over this array • Hoard/Linux slab: Efficient allocation of objects from • Just like JOS, Linux represents physical memory with a superblock/slab of pages an array of page structs – Obviously, not the exact same contents, but same idea • Pages can be allocated to processes, or to cache file data in memory 3 4 3 4 COMP 790: OS Implementation COMP 790: OS Implementation Today’s Problem The address space abstraction • Given a VMA or a file’s inode, how do I figure out • Unifying abstraction: which physical pages are storing its data? – Each file inode has an address space (0—file size) • Next lecture: We will go the other way, from a – So do block devices that cache data in RAM (0---dev size) physical page back to the VMA or file inode – The (anonymous) virtual memory of a process has an address space (0—4GB on x86) • In other words, all page
    [Show full text]
  • Altavault 4.4 Administration Guide
    Beta Draft NetApp® AltaVault™ Cloud Integrated Storage 4.4 Administration Guide NetApp, Inc. Telephone: +1 (408) 822-6000 Part number: 215-12478_A0 495 East Java Drive Fax: + 1 (408) 822-4501 November 2017 Sunnyvale, CA 94089 Support telephone: +1(888) 463-8277 U.S. Web: www.netapp.com Feedback: [email protected] Beta Draft Contents Beta Draft Contents Chapter 1 - Introduction of NetApp AltaVault Cloud Integrated Storage ............................................ 11 Overview of AltaVault....................................................................................................................................11 Supported backup applications and cloud destinations...........................................................................11 AutoSupport ............................................................................................................................................11 System requirements and specifications.........................................................................................................11 Documentation and release notes ...................................................................................................................12 Chapter 2 - Deploying the AltaVault appliance ......................................................................................13 Deployment guidelines ...................................................................................................................................13 Basic configuration.........................................................................................................................................15
    [Show full text]
  • The Parallel File System Lustre
    The parallel file system Lustre Roland Laifer STEINBUCH CENTRE FOR COMPUTING - SCC KIT – University of the State Rolandof Baden Laifer-Württemberg – Internal and SCC Storage Workshop National Laboratory of the Helmholtz Association www.kit.edu Overview Basic Lustre concepts Lustre status Vendors New features Pros and cons INSTITUTSLustre-, FAKULTÄTS systems-, ABTEILUNGSNAME at (inKIT der Masteransicht ändern) Complexity of underlying hardware Remarks on Lustre performance 2 16.4.2014 Roland Laifer – Internal SCC Storage Workshop Steinbuch Centre for Computing Basic Lustre concepts Client ClientClient Directory operations, file open/close File I/O & file locking metadata & concurrency INSTITUTS-, FAKULTÄTS-, ABTEILUNGSNAME (in der Recovery,Masteransicht ändern)file status, Metadata Server file creation Object Storage Server Lustre componets: Clients offer standard file system API (POSIX) Metadata servers (MDS) hold metadata, e.g. directory data, and store them on Metadata Targets (MDTs) Object Storage Servers (OSS) hold file contents and store them on Object Storage Targets (OSTs) All communicate efficiently over interconnects, e.g. with RDMA 3 16.4.2014 Roland Laifer – Internal SCC Storage Workshop Steinbuch Centre for Computing Lustre status (1) Huge user base about 70% of Top100 use Lustre Lustre HW + SW solutions available from many vendors: DDN (via resellers, e.g. HP, Dell), Xyratex – now Seagate (via resellers, e.g. Cray, HP), Bull, NEC, NetApp, EMC, SGI Lustre is Open Source INSTITUTS-, LotsFAKULTÄTS of organizational-, ABTEILUNGSNAME
    [Show full text]
  • Dynamically Tuning the JFS Cache for Your Job Sjoerd Visser Dynamically Tuning the JFS Cache for Your Job Sjoerd Visser
    Dynamically Tuning the JFS Cache for Your Job Sjoerd Visser Dynamically Tuning the JFS Cache for Your Job Sjoerd Visser The purpose of this presentation is the explanation of: IBM JFS goals: Where was Journaled File System (JFS) designed for? JFS cache design: How the JFS File System and Cache work. JFS benchmarking: How to measure JFS performance under OS/2. JFS cache tuning: How to optimize JFS performance for your job. What do these settings say to you? [E:\]cachejfs SyncTime: 8 seconds MaxAge: 30 seconds BufferIdle: 6 seconds Cache Size: 400000 kbytes Min Free buffers: 8000 ( 32000 K) Max Free buffers: 16000 ( 64000 K) Lazy Write is enabled Do you have a feeling for this? Do you understand the dynamic cache behaviour of the JFS cache? Or do you just rely on the “proven” cachejfs settings that the eCS installation presented to you? Do you realise that the JFS cache behaviour may be optimized for your jobs? November 13, 2009 / page 2 Dynamically Tuning the JFS Cache for Your Job Sjoerd Visser Where was Journaled File System (JFS) designed for? 1986 Advanced Interactive eXecutive (AIX) v.1 based on UNIX System V. for IBM's RT/PC. 1990 JFS1 on AIX was introduced with AIX version 3.1 for the RS/6000 workstations and servers using 32-bit and later 64-bit IBM POWER or PowerPC RISC CPUs. 1994 JFS1 was adapted for SMP servers (AIX 4) with more CPU power, many hard disks and plenty of RAM for cache and buffers. 1995-2000 JFS(2) (revised AIX independent version in c) was ported to OS/2 4.5 (1999) and Linux (2000) and also was the base code of the current JFS2 on AIX branch.
    [Show full text]
  • What Is Object Storage?
    What is Object Storage? What is object storage? How does object storage vs file system compare? When should object storage be used? This short paper looks at the technical side of why object storage is often a better building block for storage platforms than file systems are. www.object-matrix.com Object Matrix Ltd [email protected] Experts in Digital Content Governance & Object Storage +44(0)2920 382 308 The Rise of Object Storage Centera the trail blazer… What exactly Object Storage is made of will be discussed later; its benefits and its limitations included. But first of all a brief history of the rise of Object Storage: Concepts around object storage can be dated back to the 1980’s1 , but it wasn’t until around 2002 when EMC launched Centera to the world – a Content Addressable Storage product2 - that there was an object storage product for the world in general3. However, whilst Centera sold well – some sources say over 600PB were sold – there were fundamental issues with the product. In, 2005 I had a meeting with a “next Companies railed against having to use a “proprietary API” for data generation guru” of a top 3 storage access and a simple search on a search engine shows that company, and he boldly told me: “There is Centera had plenty of complaints about its performance. It wasn’t no place for Object Storage. Everything long until the industry was calling time on Centera and its “content you can do on object storage can be addressable storage” (CAS) version of object storage: not only done in the filesystem.
    [Show full text]
  • IBM Cloud Object Storage System On-Premises Features and Benefits Object Storage to Help Solve Terabytes-And-Beyond Storage Challenges
    IBM Cloud Cloud Object Storage Data Sheet IBM Cloud Object Storage System on-premises features and benefits Object storage to help solve terabytes-and-beyond storage challenges The IBM® Cloud Object Storage System™ is a breakthrough platform Highlights that helps solve unstructured data challenges for companies worldwide. It is designed to provide scalability, availability, security, • On-line scalability that offers a single manageability, flexibility, and lower total cost of ownership (TCO). storage system and namespace • Security features include a wide The Cloud Object Storage System is deployed in multiple range of capabilities designed to meet configurations as shown in Figure 1. Each node consists of Cloud security requirements Object Storage software running on an industry-standard server. • Reliability and availability characteristics Cloud Object Storage software is compatible with a wide range of of the system are configurable servers from many sources, including a physical or virtual appliance. • Single copy protected data with In addition, IBM conducts certification of specific servers that geo-dispersal creating both efficiency customers want to use in their environment to help insure quick and manageability initial installation, long-term reliability and predictable performance. • Compliance enabled vaults for when compliance requirements or locking down data is required Data source Multiple concurrent paths ACCESSER® LAYER ......... Multiple concurrent paths SLICESTOR® LAYER ......... Figure 1: Multiple configurations of
    [Show full text]
  • NOVA: a Log-Structured File System for Hybrid Volatile/Non
    NOVA: A Log-structured File System for Hybrid Volatile/Non-volatile Main Memories Jian Xu and Steven Swanson, University of California, San Diego https://www.usenix.org/conference/fast16/technical-sessions/presentation/xu This paper is included in the Proceedings of the 14th USENIX Conference on File and Storage Technologies (FAST ’16). February 22–25, 2016 • Santa Clara, CA, USA ISBN 978-1-931971-28-7 Open access to the Proceedings of the 14th USENIX Conference on File and Storage Technologies is sponsored by USENIX NOVA: A Log-structured File System for Hybrid Volatile/Non-volatile Main Memories Jian Xu Steven Swanson University of California, San Diego Abstract Hybrid DRAM/NVMM storage systems present a host of opportunities and challenges for system designers. These sys- Fast non-volatile memories (NVMs) will soon appear on tems need to minimize software overhead if they are to fully the processor memory bus alongside DRAM. The result- exploit NVMM’s high performance and efficiently support ing hybrid memory systems will provide software with sub- more flexible access patterns, and at the same time they must microsecond, high-bandwidth access to persistent data, but provide the strong consistency guarantees that applications managing, accessing, and maintaining consistency for data require and respect the limitations of emerging memories stored in NVM raises a host of challenges. Existing file sys- (e.g., limited program cycles). tems built for spinning or solid-state disks introduce software Conventional file systems are not suitable for hybrid mem- overheads that would obscure the performance that NVMs ory systems because they are built for the performance char- should provide, but proposed file systems for NVMs either in- acteristics of disks (spinning or solid state) and rely on disks’ cur similar overheads or fail to provide the strong consistency consistency guarantees (e.g., that sector updates are atomic) guarantees that applications require.
    [Show full text]
  • File Systems and Storage
    FILE SYSTEMS AND STORAGE On Making GPFS Truly General DEAN HILDEBRAND AND FRANK SCHMUCK Dean Hildebrand manages the PFS (also called IBM Spectrum Scale) began as a research project Cloud Storage Software team that quickly found its groove supporting high performance comput- at the IBM Almaden Research ing (HPC) applications [1, 2]. Over the last 15 years, GPFS branched Center and is a recognized G expert in the field of distributed out to embrace general file-serving workloads while maintaining its original and parallel file systems. He pioneered pNFS, distributed design. This article gives a brief overview of the origins of numer- demonstrating the feasibility of providing ous features that we and many others at IBM have implemented to make standard and scalable access to any file GPFS a truly general file system. system. He received a BSc degree in computer science from the University of British Columbia Early Days in 1998 and a PhD in computer science from Following its origins as a project focused on high-performance lossless streaming of multi- the University of Michigan in 2007. media video files, GPFS was soon enhanced to support high performance computing (HPC) [email protected] applications, to become the “General Parallel File System.” One of its first large deployments was on ASCI White in 2002—at the time, the fastest supercomputer in the world. This HPC- Frank Schmuck joined IBM focused architecture is described in more detail in a 2002 FAST paper [3], but from the outset Research in 1988 after receiving an important design goal was to support general workloads through a standard POSIX inter- a PhD in computer science face—and live up to the “General” term in the name.
    [Show full text]
  • Hibachi: a Cooperative Hybrid Cache with NVRAM and DRAM for Storage Arrays
    Hibachi: A Cooperative Hybrid Cache with NVRAM and DRAM for Storage Arrays Ziqi Fan, Fenggang Wu, Dongchul Parkx, Jim Diehl, Doug Voigty, and David H.C. Du University of Minnesota–Twin Cities, xIntel Corporation, yHewlett Packard Enterprise Email: [email protected], ffenggang, park, [email protected], [email protected], [email protected] Abstract—Adopting newer non-volatile memory (NVRAM) Application Application Application technologies as write buffers in slower storage arrays is a promising approach to improve write performance. However, due OS … OS … OS to DRAM’s merits, including shorter access latency and lower Buffer/Cache Buffer/Cache Buffer/Cache cost, it is still desirable to incorporate DRAM as a read cache along with NVRAM. Although numerous cache policies have been Application, web or proposed, most are either targeted at main memory buffer caches, database servers or manage NVRAM as write buffers and separately manage DRAM as read caches. To the best of our knowledge, cooperative hybrid volatile and non-volatile memory buffer cache policies specifically designed for storage systems using newer NVRAM Storage Area technologies have not been well studied. Network (SAN) This paper, based on our elaborate study of storage server Hibachi Cache block I/O traces, proposes a novel cooperative HybrId NVRAM DRAM NVRAM and DRAM Buffer cACHe polIcy for storage arrays, named Hibachi. Hibachi treats read cache hits and write cache hits differently to maximize cache hit rates and judiciously adjusts the clean and the dirty cache sizes to capture workloads’ tendencies. In addition, it converts random writes to sequential writes for high disk write throughput and further exploits storage server I/O workload characteristics to improve read performance.
    [Show full text]
  • DAOS: Revolutionizing High-Performance Storage with Intel® Optane™ Technology
    SOLUTION BRIEF Distributed Asynchronous Object Storage (DAOS) Intel® Optane™ Technology DAOS: Revolutionizing High-Performance Storage with Intel® Optane™ Technology With the exponential growth of data, distributed storage systems have become not only the heart, but also the bottleneck of data centers. High-latency data access, poor scalability, difficulty managing large datasets, and lack of query capabilities are just a few examples of common hurdles. Traditional storage systems have been designed for rotating media and for POSIX* input/output (I/O). These storage systems represent a key performance bottleneck, and they cannot evolve to support new data models and next-generation workflows. The Convergence of HPC, Big Data, and AI Storage requirements have continued to evolve, with the need to manipulate ever-growing datasets driving a further need to remove barriers between data and compute. Storage is no longer driven by traditional workloads with large streaming writes like checkpoint/restart, but is increasingly driven by complex I/O patterns from new storage pillars. High-performance data-analytics workloads are generating vast quantities of random reads and writes. Artificial-intelligence (AI) workloads are reading far more than traditional high-performance computing (HPC) workloads. Data streaming from instruments into an HPC cluster require better quality of service (QoS) to avoid data loss. Data-access time is now becoming as critical as write bandwidth. New storage semantics are required to query, analyze, filter, and transform datasets. A single storage platform in which next-generation workflows combine HPC, big data, and AI to exchange data and communicate is essential. DAOS Software Stack Intel has been building an entirely open source software ecosystem for data-centric computing, fully optimized for Intel® architecture and non-volatile memory (NVM) technologies, including Intel® Optane™ DC persistent memory and Intel Optane DC SSDs.
    [Show full text]
  • Capsule: an Energy-Optimized Object Storage System for Memory-Constrained Sensor Devices
    Capsule: An Energy-Optimized Object Storage System for Memory-Constrained Sensor Devices Gaurav Mathur, Peter Desnoyers, Deepak Ganesan, Prashant Shenoy {gmathur, pjd, dganesan, shenoy}@cs.umass.edu Department of Computer Science University of Massachusetts, Amherst, MA 01003 Abstract 1 Introduction Recent gains in energy-efficiency of new-generation NAND flash stor- Storage is an essential ingredient of any data-centric sen- age have strengthened the case for in-network storage by data-centric sensor sor network application. Common uses of storage in sen- network applications. This paper argues that a simple file system abstrac- sor applications include archival storage [9], temporary data tion is inadequate for realizing the full benefits of high-capacity low-power storage [6], storage of sensor calibration tables [10], in- NAND flash storage in data-centric applications. Instead we advocate a network indexing [20], in-network querying [19] and code rich object storage abstraction to support flexible use of the storage system storage for network reprogramming [7], among others. Until for a variety of application needs and one that is specifically optimized for recently, sensor applications and systems were designed un- memory and energy-constrained sensor platforms. We propose Capsule, an der the assumption that computation is significantly cheaper energy-optimized log-structured object storage system for flash memories that both communication and storage, with the latter two in- that enables sensor applications to exploit storage resources in a multitude of curring roughly equal costs. However, the emergence of a ways. Capsule employs a hardware abstraction layer that hides the vagaries new generation of NAND flash storage has significantly al- of flash memories for the application and supports energy-optimized imple- tered this trade-off, with a recent study showing that flash mentations of commonly used storage objects such as streams, files, arrays, storage is now two orders of magnitude cheaper than com- queues and lists.
    [Show full text]