DOCSLIB.ORG

Recovery Techniques to Improve File System Reliability

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

RECOVERY TECHNIQUES TO IMPROVE FILE SYSTEM RELIABILITY by Swaminathan Sundararaman B.E. (Hons.) Computer Science (Birla Institute of Technology and Science (Pilani), India) 2005 M.S. Computer Sciences (Stony Brook University) 2007 A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Sciences University of Wisconsin-Madison 2011 Committee in charge: Prof. Andrea C. Arpaci-Dusseau (Co-chair) Prof. Remzi H. Arpaci-Dusseau (Co-chair) Prof. Ben Liblit Prof. Michael M. Swift Prof. Shan Lu Prof. Jon Eckhardt ii iv v To my parents vi vii Acknowledgements I would like to express my heart-felt thanks to my advisors, Andrea Arpaci-Dusseau and Remzi Arpaci-Dusseau, who guided me in this endeavor and taught me how to do research. I always wanted to build really cool systems during my Ph.D. Not only did they let me do this, but they also taught me the valuable lesson that solutions (or systems) are just a small part of doing research. I also learnt the importance of clarity in both writing and presentation from them. I would like to thank Andrea for teaching me the values of patience, good ques- tions, and paying attention to details. I would like to thank Remzi for helping me select interesting projects and, most importantly, for showing me that research is a lot of fun. I am ever grateful to Remzi for taking the time to write me a long email and talk with me on the phone while I was deciding between universities. If not for that email, I would have ended up taking a full-time position at one of the companies in the Bay Area – and regretted not doing a Ph.D. for the rest of my life. I am grateful to my thesis committee members – Mike Swift, Ben Liblit, Shan Lu, and Jon Eckhardt – for their insightful comments and suggestions. Their feed- back during my preliminary and final exams improved this thesis greatly. I would like to thank Mike Swift for collaborating with us on the Membrane project. It was one of the best learning experiences for me. During our meetings, he would go into the smallest implementation detail and then quickly switch back to the big picture ideas. After my meetings with him, I would go back and spend a few hours trying to understand what he had been able to say in only a few seconds during the meetings. I am thankful to Sriram Subramanian for putting up with me during my best and worst times in Madison. Even though both of us graduated together from BITS, we hardly knew each other at the time we came to the UW. The friendship began with me sending him an email asking if he wanted to be my roommate – to which he agreed. Since then, it has been a great journey; he has been my roommate for the last four years, office mate for three years, project mate and a collaborator for last four years, and last but not least, a great friend. I have spent many hours viii brainstorming ideas with him and he has helped a lot in refining and validating my ideas and designs. I am fortunate to have had the opportunity to work with smart and hardworking colleagues during the course of my Ph.D.: Leo Arulraj, Lakshmi Bairavasundaram, Abhishek Rajimwale, Sriram Subramanian, Laxman Visampalli, Yiying Zhang, and Yupu Zhang. I also have enjoyed interacting with other members in the group: Ishani Ahuja, Nitin Agrawal, Vijay Chidambaram, Thanh Do, Haryadi Gunawi, Tyler Harter, Ao Ma, Joe Meehean, Thanumallayan Pillai, Deepak Ramamurthi, Lanyue Lu, Suli Yang. I would especially like to thank Abhishek, Sriram, Laxman, and Yupu for their hard work, contributions, and often burning the midnight oil with me during deadline times. A lot of my motivation for pursuing a Ph.D. came from my experiences at Stony Brook University and Birla Institute of Technology and Science (BITS). I would like to especially thank my advisors: Erez Zadok at Stony Brook, for fostering in me an interest in file and storage systems and teaching me that kernel programming is a lot of fun; Rahul Banerjee at BITS, for enabling me to think big and dream about projects that were beyond my capabilities; and Sundar Balasubramanian at BITS, for teaching me the importance of novelty and creativity in doing research. I have benefited greatly from interning at VMware, Microsoft Research, and EPFL. I would like to thank the organizations as well as my mentors and managers there: Satyam Vaghani at VMware, Dennis Fetterly at Microsoft Research, and George Candea at EPFL. I would also like to thank the other collaborators at these organizations: Abhishek Rai, Yunlin Tan, and Mayank Rawat at VMware; Michael Isard and Chandu Thekkath at Microsoft Research; and Vitaly Chipounov and Vova Kuznetsov at EPFL. I would like to thank my friends for making my stay in Madison enjoyable. To name a few: Koushik Narasimhan, Srinath Sridharan, Uthra Srinath, Pira- manayagam Arumuga Nainar, Siddharth Barman, Asim Kadav, Janani Kalyanam, Ashok Anand, Deepthi Pachauri, Giri Ravipati, Rathijit Sen, Neelam Goyal, Nikhil Teletia, and Abhishek Iyer. They were happy even for my small successes and cheered me during difficult times. I am going to miss all the fun we had: evening movies, potluck dinners, tennis, cricket, poker sessions, and road trips. I would like to specially thank Kaushik for coming up with fancy names and for the con- stant nudging during deadlines, which kept it fun for me. Finally, I would like to thank my family, without whose love and support this Ph.D. would have been impossible. Most of the credit, however, is due to my parents. They live their life to make me happy, and they have given me everything I have needed to find my way in the world and succeed. They have always been very ix supportive of my decisions and have been the two pillars that I can always lean on. My sister, Harini, has cheered me on during the entire course of my Ph.D. I would also like to thank my cousin, Rajesh, and his wife, Niranjana, for their constant encouragement and support. Finally, I would also like to thank all my relatives who always encouraged and supported me in all of my endeavors. x xi Abstract RECOVERY TECHNIQUES TO IMPROVE FILE SYSTEM RELIABILITY Swaminathan Sundararaman We implement selective restart and resource reservation for commodity file systems to improve their reliability. Selective restart allows file systems to quickly recover from failures; resource reservation enables file systems to avoid certain failures altogether. Together they enable a new class of more robust and reliable file systems to be realized. In the first part of this dissertation (on selective restart), we develop Membrane, a generic framework built inside the operating system to selectively restart kernel- level file systems. Membrane allows an operating system to tolerate a broad class of file system failures and does so while remaining transparent to running applica- tions; upon failure, the file system restarts, its state is restored, and pending applica- tion requests are serviced as if no failure had occurred. We also develop Re-FUSE, a generic framework designed to restart user-level file systems upon failures. Re- FUSE monitors the user-level file-system and on a crash restarts the file system and restores its state; the restart process is completely transparent to applications. We evaluate both Membrane and Re-FUSE, and show, through experimentation, that both of these frameworks induce little performance and space overhead and can tolerate a wide range of crashes with minimal code change. In the second part of the dissertation (on resource reservation), we develop An- ticipatory Memory Allocation (AMA), a technique that uses static analysis to sim- plify recovery code dealing with memory-allocation failures. AMA determines the memory requirements of a particular call into a file system, and then pre-allocates said amount immediately upon entry; subsequent allocation requests are serviced from the pre-allocated pool and thus guaranteed never to fail. We evaluate AMA by transforming Linux ext2 file system into a memory-failure robust version of it- self (called ext2-mfr). Experiments reveal that ext2-mfr avoids memory-allocation failures successfully while incurring little space and time overheads. xii Contents Acknowledgements vii Abstract xi 1 Introduction 1 1.1 Reliability Through Restartability . 3 1.2 Reliability Through Reservation . 6 1.3 Contributions ............................ 8 1.4 Outline ............................... 9 2 File Systems 11 2.1 Overview .............................. 11 2.2 File System Components . 15 2.3 Handling Application Requests . 16 2.4 On-DiskState............................ 17 2.5 Consistency ............................. 20 2.5.1 Journaling.......................... 21 2.5.2 Snapshotting ........................ 22 2.6 DeploymentTypes ......................... 23 2.6.1 Kernel-level File Systems . 23 2.6.2 User-level File Systems . 24 2.7 Summary .............................. 25 3 Reliability through Restartability 27 3.1 FailureModel............................ 28 3.1.1 Definitions ......................... 28 3.1.2 Taxonomy of Faults . 29 3.1.3 SystemModel ....................... 29 3.1.4 Behavior of Systems on Failures . 29 xiii xiv 3.1.5 Occurrence Pattern . 32 3.1.6 Operating System Response to a Failure . 32 3.1.7 OurApproach........................ 33 3.2 Restarting a file system . 34 3.2.1 Goals ............................ 34 3.2.2 State Associated with File Systems . 35 3.2.3 Different Ways to Restart a File System . 37 3.3 Components of a Restartable Framework . 39 3.3.1 Fault Detection . 39 3.3.2 Fault Anticipation . 40 3.3.3 FaultRecovery ....................... 41 3.4 Summary .............................. 42 4 Restartable Kernel-level File Systems 43 4.1 Design................................ 44 4.1.1 Overview .........................
Recommended publications
  • Copy on Write Based File Systems Performance Analysis and Implementation

    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.
  • Membrane: Operating System Support for Restartable File Systems Swaminathan Sundararaman, Sriram Subramanian, Abhishek Rajimwale, Andrea C

    Membrane: Operating System Support for Restartable File Systems Swaminathan Sundararaman, Sriram Subramanian, Abhishek Rajimwale, Andrea C

    Membrane: Operating System Support for Restartable File Systems Swaminathan Sundararaman, Sriram Subramanian, Abhishek Rajimwale, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau, Michael M. Swift Computer Sciences Department, University of Wisconsin, Madison Abstract and most complex code bases in the kernel. Further, We introduce Membrane, a set of changes to the oper- file systems are still under active development, and new ating system to support restartable file systems. Mem- ones are introduced quite frequently. For example, Linux brane allows an operating system to tolerate a broad has many established file systems, including ext2 [34], class of file system failures and does so while remain- ext3 [35], reiserfs [27], and still there is great interest in ing transparent to running applications; upon failure, the next-generation file systems such as Linux ext4 and btrfs. file system restarts, its state is restored, and pending ap- Thus, file systems are large, complex, and under develop- plication requests are serviced as if no failure had oc- ment, the perfect storm for numerous bugs to arise. curred. Membrane provides transparent recovery through Because of the likely presence of flaws in their imple- a lightweight logging and checkpoint infrastructure, and mentation, it is critical to consider how to recover from includes novel techniques to improve performance and file system crashes as well. Unfortunately, we cannot di- correctness of its fault-anticipation and recovery machin- rectly apply previous work from the device-driver litera- ery. We tested Membrane with ext2, ext3, and VFAT. ture to improving file-system fault recovery. File systems, Through experimentation, we show that Membrane in- unlike device drivers, are extremely stateful, as they man- duces little performance overhead and can tolerate a wide age vast amounts of both in-memory and persistent data; range of file system crashes.
  • Ivoyeur: Inotify

    Ivoyeur: Inotify

    COLUMNS iVoyeur inotify DAVE JOSEPHSEN Dave Josephsen is the he last time I changed jobs, the magnitude of the change didn’t really author of Building a sink in until the morning of my first day, when I took a different com- Monitoring Infrastructure bination of freeways to work. The difference was accentuated by the with Nagios (Prentice Hall T PTR, 2007) and is Senior fact that the new commute began the same as the old one, but on this morn- Systems Engineer at DBG, Inc., where he ing, at a particular interchange, I would zig where before I zagged. maintains a gaggle of geographically dispersed It was an unexpectedly emotional and profound metaphor for the change. My old place was server farms. He won LISA ‘04’s Best Paper off to the side, and down below, while my future was straight ahead, and literally under award for his co-authored work on spam construction. mitigation, and he donates his spare time to the SourceMage GNU Linux Project. The fact that it was under construction was poetic but not surprising. Most of the roads I [email protected] travel in the Dallas/Fort Worth area are under construction and have been for as long as anyone can remember. And I don’t mean a lane closed here or there. Our roads drift and wan- der like leaves in the water—here today and tomorrow over there. The exits and entrances, neither a part of this road or that, seem unable to anticipate the movements of their brethren, and are constantly forced to react.
  • Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO

    Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO

    Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO..........................................................................................................................................1 Martin Hinner < [email protected]>, http://martin.hinner.info............................................................1 1. Introduction..........................................................................................................................................1 2. Volumes...............................................................................................................................................1 3. DOS FAT 12/16/32, VFAT.................................................................................................................2 4. High Performance FileSystem (HPFS)................................................................................................2 5. New Technology FileSystem (NTFS).................................................................................................2 6. Extended filesystems (Ext, Ext2, Ext3)...............................................................................................2 7. Macintosh Hierarchical Filesystem − HFS..........................................................................................3 8. ISO 9660 − CD−ROM filesystem.......................................................................................................3 9. Other filesystems.................................................................................................................................3
  • Using Hierarchical Folders and Tags for File Management

    Using Hierarchical Folders and Tags for File Management

    Using Hierarchical Folders and Tags for File Management A Thesis Submitted to the Faculty of Drexel University by Shanshan Ma in partial fulfillment of the requirement for the degree of Doctor of Philosophy March 2010 © Copyright 2010 Shanshan Ma. All Rights Reserved. ii Dedications This dissertation is dedicated to my mother. iii Acknowledgments I would like to express my sincerest gratitude to my advisor Dr. Susan Wiedenbeck. She encouraged me when I had struggles. She inspired me when I had doubts. The dissertation is nowhere to be found if it had not been for our weekly meetings and numerous discussions. I’m in great debts to all the time and effort that she spent with me in this journey. Thank you to my dissertation committee members, Dr. Michael Atwood, Dr. Xia Lin, Dr. Denise Agosto, and Dr. Deborah Barreau, who have guided me and supported me in the research. The insights and critiques from the committee are invaluable in the writing of this dissertation. I am grateful to my family who love me unconditionally. Thank you my mother for teaching me to be a strong person. Thank you my father and my brother for always being there for me. I would like to thank the iSchool at Drexel University for your generosity in supporting my study and research, for your faculty and staff members who I always had fun to work with, and for the alumni garden that is beautiful all year round. Thank you my friends in Philadelphia and my peer Ph.D. students in the iSchool at Drexel University.
  • Model-Based Failure Analysis of Journaling File Systems

    Model-Based Failure Analysis of Journaling File Systems

    Model-Based Failure Analysis of Journaling File Systems Vijayan Prabhakaran, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau University of Wisconsin, Madison Computer Sciences Department 1210, West Dayton Street, Madison, Wisconsin {vijayan, dusseau, remzi}@cs.wisc.edu Abstract To analyze such file systems, we develop a novel model- based fault-injection technique. Specifically, for the file We propose a novel method to measure the dependability system under test, we develop an abstract model of its up- of journaling file systems. In our approach, we build models date behavior, e.g., how it orders writes to disk to maintain of how journaling file systems must behave under different file system consistency. By using such a model, we can journaling modes and use these models to analyze file sys- inject faults at various “interesting” points during a file sys- tem behavior under disk failures. Using our techniques, we tem transaction, and thus monitor how the system reacts to measure the robustness of three important Linux journaling such failures. In this paper, we focus only on write failures file systems: ext3, Reiserfs and IBM JFS. From our anal- because file system writes are those that change the on-disk ysis, we identify several design flaws and correctness bugs state and can potentially lead to corruption if not properly present in these file systems, which can cause serious file handled. system errors ranging from data corruption to unmountable We use this fault-injection methodology to test three file systems. widely used Linux journaling file systems: ext3 [19], Reis- erfs [14] and IBM JFS [1].
  • Monitoring File Events

    Monitoring File Events

    MONITORING FILE EVENTS Some applications need to be able to monitor files or directories in order to deter- mine whether events have occurred for the monitored objects. For example, a graphical file manager needs to be able to determine when files are added or removed from the directory that is currently being displayed, or a daemon may want to monitor its configuration file in order to know if the file has been changed. Starting with kernel 2.6.13, Linux provides the inotify mechanism, which allows an application to monitor file events. This chapter describes the use of inotify. The inotify mechanism replaces an older mechanism, dnotify, which provided a subset of the functionality of inotify. We describe dnotify briefly at the end of this chapter, focusing on why inotify is better. The inotify and dnotify mechanisms are Linux-specific. (A few other systems provide similar mechanisms. For example, the BSDs provide the kqueue API.) A few libraries provide an API that is more abstract and portable than inotify and dnotify. The use of these libraries may be preferable for some applications. Some of these libraries employ inotify or dnotify, on systems where they are available. Two such libraries are FAM (File Alteration Monitor, http:// oss.sgi.com/projects/fam/) and Gamin (http://www.gnome.org/~veillard/gamin/). 19.1 Overview The key steps in the use of the inotify API are as follows: 1. The application uses inotify_init() to create an inotify instance. This system call returns a file descriptor that is used to refer to the inotify instance in later operations.
  • A File System Level Snapshot in Ext4

    A File System Level Snapshot in Ext4

    Computer Engineering and Intelligent Systems www.iiste.org ISSN 2222-1719 (Paper) ISSN 2222-2863 (Online) Vol 2, No.8, 2011 A File System Level Snapshot In Ext4 Uma Nagaraj Computer Engineering Department, Pune University, MAE, Alandi Pune, Maharashtra 412105, India E-mail: [email protected] Ganesh Patil Computer Engineering Department, Pune University, MAE, Alandi Pune, Maharashtra 412105, India E-mail: [email protected] Swapnil Gaikwad Computer Engineering Department, Pune University, MAE, Alandi Pune, Maharashtra 412105, India E-mail: [email protected] Akshay Nehe Computer Engineering Department, Pune University, MAE, Alandi Pune, Maharashtra 412105, India E-mail: [email protected] Ashish Mayekar Computer Engineering Department, Pune University, MAE, Alandi Pune, Maharashtra 412105, India E-mail: [email protected] Received: 2011-10-20 Accepted: 2011-10-29 Published:2011-11-04 Abstract Snapshot makes a copy of current working system. Creating a snapshot with some processing and overheads is important to provide the reliable data service during backup. There are two types of snapshot techniques: volume-based approach and system-based approach. The volume-based Logical Volume Manager provides compact space usability, but requires some space to save snapshot and makes system with extra overheads. The system-based Snapshot works better than volume based. The file system based Snapshot does not need reserve space for snapshot. Therefore, the system-based Snapshot is considered a good solution in the computer environment where large-scale space management capability is not that critical. However, such snapshot feature is available in Linux kernel 2.2, 2.6 in EXT3 file system. In this paper, we proposed a system-based snapshot for the ext4 system in Linux kernel 2.6 or higher.
  • Kernel Korner

    Kernel Korner

    Kernel Korner http://0-delivery.acm.org.innopac.lib.ryerson.ca/10.1145/1110000/11030... Kernel Korner Intro to inotify Robert Love Abstract Applications that watch thousands of files for changes, or that need to know when a storage device gets disconnected, need a clean, fast solution to the file change notification problem. Here it is. John McCutchan and I had been working on inotify for about a year when it was finally merged into Linus' kernel tree and released with kernel version 2.6.13. Although a long struggle, the effort culminated in success and was ultimately worth every rewrite, bug and debate. What Is inotify? inotify is a file change notification system—a kernel feature that allows applications to request the monitoring of a set of files against a list of events. When the event occurs, the application is notified. To be useful, such a feature must be simple to use, lightweight with little overhead and flexible. It should be easy to add new watches and painless to receive notification of events. To be sure, inotify is not the first of its kind. Every modern operating system provides some sort of file notification system; many network and desktop applications require such functionality—Linux too. For years, Linux has offered dnotify. The problem was, dnotify was not very good. In fact, it stank. dnotify, which ostensibly stands for directory notify, was never considered easy to use. Sporting a cumbersome interface and several painful features that made life arduous, dnotify failed to meet the demands of the modern desktop, where asynchronous notification of events and a free flow of information rapidly are becoming the norm.
  • VERSIONFS a Versatile and User-Oriented Versioning File System

    VERSIONFS a Versatile and User-Oriented Versioning File System

    VERSIONFS A Versatile and User-Oriented Versioning File System A THESIS PRESENTED BY KIRAN-KUMAR MUNISWAMY-REDDY TO THE GRADUATE SCHOOL IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE IN COMPUTER SCIENCE STONY BROOK UNIVERSITY Technical Report FSL-03-03 December 2003 Abstract of the Thesis Versionfs A Versatile and User-Oriented Versioning File System by Kiran-Kumar Muniswamy-Reddy Master of Science in Computer Science Stony Brook University 2003 File versioning is a useful technique for recording a history of changes. Applications of ver- sioning include backups and disaster recovery, as well as monitoring intruders’ activities. Alas, modern systems do not include an automatic and easy-to-use file versioning system. Existing backup systems are slow and inflexible for users. Even worse, they often lack backups for the most recent day’s activities. Online disk snapshotting systems offer more fine-grained versioning, but still do not record the most recent changes to files. Moreover, existing systems also do not give individual users the flexibility to control versioning policies. We designed a lightweight user-oriented versioning file system called Versionfs. Versionfs works with any file system, whether local or remote, and provides a host of user-configurable policies: versioning by users, groups, processes, or file names and extensions; version retention policies by maximum number of versions kept, age, or total space consumed by versions of a file; version storage policies using full copies, compressed copies, or deltas. Versionfs creates file versions automatically, transparently, and in a file-system portable manner—while maintaining Unix semantics. A set of user-level utilities allow administrators to configure and enforce default policies; users are able to set policies within configured boundaries, as well as view, control, and recover files and their versions.
  • Displaying and Watching Directories Using Lazarus

    Displaying and Watching Directories Using Lazarus

    Displaying and Watching directories using Lazarus Michaël Van Canneyt October 31, 2011 Abstract Using Lazarus, getting the contents of a directory can be done in 2 ways: a portable, and a unix-specific way. This article shows how to get the contents of a directory and show it in a window. Additionally, it shows how to get notifications of the Linux kernel if the contents of the directory changes. 1 Introduction Examining the contents of a directory is a common operation, both using command-line tools or a GUI file manager. Naturally, Free/Pascal and Lazarus offer an API to do this. In fact, there are 2 API’s to get the contents of a directory: one which is portable and will work on all platforms supported by Lazarus. The other is not portable, but resembles closely the POSIX API for dealing with files and directories. Each API has its advantages and disadvantages. Often, it is desirable to be notified if the contents of a directory changes: in a file manager, this can be used to update the display - showing new items or removing items as needed. This can also be done by scanning the contents of the directory at regular intervals, but it should be obvious that this is not as efficient. There are other scenarios when a notification of a change in a directory is interesting: for instance, in a FTP server, one may want to move incoming files to a location outside the FTP tree, or to a new location based on some rules (e.g. images to one directory, sound files to another).
  • The Third Extended File System with Copy-On-Write

    The Third Extended File System with Copy-On-Write

    Limiting Liability in a Federally Compliant File System Zachary N. J. Peterson The Johns Hopkins University Hopkins Storage Systems Lab, Department of Computer Science Regulatory Requirements z Data Maintenance Acts & Regulations – HIPAA, GISRA, SOX, GLB – 4,000+ State and Federal Laws and Regulations with regards to storage z Audit Trail – creating a “chain of trust” – Files are versioned over time – Authenticated block sharing (copy-on-write) between versions. z Disk Encryption – Privacy and Confidentiality – Non-repudiation Hopkins Storage Systems Lab, Department of Computer Science Secure Deletion in a Regulatory Environment z Desire to limit liability when audited – Records that go out of audit scope do so forever – When a disk is subpoenaed old or irrelevant data are inaccessible z Existing Techniques – Secure overwrite [Gutmann] – File key disposal in disk encrypted systems [Boneh & Lipton] z Existing solutions don’t work well in block- versioning file systems Hopkins Storage Systems Lab, Department of Computer Science Technical Problems z Secure overwriting of noncontiguous data blocks is slow and inefficient – When versions share blocks, data to be overwritten may be noncontiguous z Cannot dispose file keys in a versioning file system – Blocks encrypted with a particular key need to be available in future versions z User space tools are inadequate – Can’t delete metadata – Can’t be interposed between file operations – Truncate may leak data – Difficult to be synchronous Hopkins Storage Systems Lab, Department of Computer Science