DOCSLIB.ORG

AMD Alchemy™ Processors Building a Root File System for Linux® Incorporating Memory Technology Devices

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
AMD Alchemy™ Processors Building a Root File System for Linux® Incorporating Memory Technology Devices AMD Alchemy™ Processors Building a Root File System for Linux® Incorporating Memory Technology Devices 1.0 Scope This document outlines a step-by-step process for building and deploying a Flash-based root file system for Linux® on an AMD Alchemy™ processor-based development board, using an approach that incorporates Memory Technology Devices (MTDs) with the JFFS2 file system. Note: This document describes creating a root file system on NOR Flash memory devices, and does not apply to NAND Flash devices. 1.1 Journaling Flash File System JFFS2 is the second generation of the Journaling Flash File System (JFFS). This file system provides a crash-safe and powerdown-safe Linux file system for use with Flash memory devices. The home page for the JFFS project is located at http://developer.axis.com/software/jffs. 1.2 Memory Technology Device The MTD subsystem provides a generic Linux driver for a wide range of memory devices, including Flash memory devices. This driver creates an abstracted device used by JFFS2 to interface to the actual Flash memory hardware. The home page for the MTD project is located at http://www.linux-mtd.infradead.org. 2.0 Building the Root File System Before being deployed to an AMD Alchemy platform, the file system must first be built on an x86 Linux host PC. The pri- mary concern when building a Flash-based root file system is often the size of the image. The file system must be designed so that it fits within the available space of the Flash memory, with enough extra space to accommodate any runtime-created files, such as temporary or log files. Before moving on to the deployment phase, the root file system should be tested using either an NFS-based or hard disk- based configuration to ensure its functionality. 2.1 OpenEmbedded Root File System A root file system generated by the OpenEmbedded (OE) toolkit is often suitable for deployment onto a Flash device with- out any major modifications. The AMD Alchemy™ Au1200™ OE Development Kit is configured to build a BusyBox-based system by default, and it is not recommended that this be changed unless absolutely necessary. To ensure no space is wasted, include only those packages necessary for operation of the system in the platform’s OE meta-package before building the image. To follow the steps for deployment, use the generated root file system located in the travis-dev-kit/tmp/rootfs directory if using the directory structure outlined in the AMD Alchemy™ DBAu1200™ Develo- pent Board OpenEmbedded Quick Start Guide (Publication ID 40351). 2.2 MontaVista Root File System The MontaVista Pro toolkit includes a very large pre-built root file system. This file system must be reduced using an itera- tive process until its footprint fits into the available Flash memory. It is highly recommended that the file system be deployed using NFS during the reduction process, as any changes can be tested immediately. 2.2.1 BusyBox The first step in reducing the footprint of the MontaVista root file system is to switch from the default Bash shell and coreutils to a BusyBox-based system. BusyBox is a single multi-call binary that replaces and replicates the basic and most- used functionality of the shell and many of the necessary utilities for running a Linux system. The BusyBox binary is approx- imately 1 MB in size, and can be built to rely on no external libraries except for the C library, libc. 40755A - May 2006 - Confidential 1 Application Note 40755A - May 2006 - Confidential The BusyBox source code and documentation can be obtained at http://www.busybox.net. While BusyBox advocates the use of uClibc, a smaller version of the C library, it is entirely possible, and often desirable, to build BusyBox to use the pre- compiled C library contained within the original MontaVista root file system. 2.2.2 Removing Unnecessary Packages The most time consuming portion of reducing the MontaVista footprint is removing the packages that are not necessary for the target system. This can be done in a top-down manner, by removing a subset of the unnecessary packages and then testing the file system, or in a bottom-up manner by starting with only BusyBox and adding additional necessary packages one-at-a-time and resolving dependency errors that arise. The method chosen depends largely on developer preference. In either case, it is helpful to use the ldd tool (ensure a MIPS-based tool is used (e.g., mips_nfp_le-ldd)) to determine the library dependencies of a dynamically-linked binary executable. 2.2.3 Removing Debug Information The MontaVista root file system binaries and libraries are built with debugging symbols included. While this is beneficial when debugging software, it can also greatly increase the size of the executable. Once the file system has been reduced to its necessary functionality, the debugging information can be removed from the included binaries, further reducing the foot- print of the file system. This is done using the strip tool, as shown in the following example, which removes the debugging symbols from the C library: # mips_nfp_le-strip -d libc-2.3.2.so 3.0 Deploying a JFFS2 File System Once the file system has been built on the x86 host PC and tested on the target platform, the file system must then be con- verted into a JFFS2 image and written to Flash. 3.1 Add MTD Support to the Linux Kernel The Linux kernel must be configured to support MTD and JFFS2. Since the root file system will be mounted using JFFS2, all of the kernel options must be enabled as built-ins, not as modules. For a Linux 2.4 kernel on a AMD Alchemy™ DBAu1550™ development board, enable the following options: Memory Technology Devices (MTD) ---> <*> Memory Technology Device (MTD) Support <*> MTD Partitioning Support RAM/ROM/Flash chip drivers ---> <*> Detect flash chips by Common Flash Interface (CFI) probe <*> Support for AMD/Fujitsu Flash Chips Mapping drivers for chip access ---> <*> Db1550 MTD Support File systems ---> <*> Journalling Flash File System v2 (JFFS2) support For a Linux 2.6 kernel on a AMD Alchemy™ DBAu1200™ development board, enable the following options: Device Drivers ---> Memory Technology Devices (MTD) ---> <*> Memory Technology Device (MTD) support [*] MTD partitioning support RAM/ROM/Flash chip drivers ---> <*> Detect flash chips by Common Flash Interface (CFI) probe <*> Support for AMD/Fujitsu flash chips Mapping drivers for chip access ---> <*> AMD Alchemy Pb1xxx/Db1xxx/RDK MTD support File systems ---> Miscellaneous filesystems ---> <*> Journalling Flash File System v2 (JFFS2) support 2 AMD Alchemy™ Processors Building a Root File System for Linux® Incorporating Memroy Technology Devices Application Note 40755A - May 2006 - Confidential The MTD mappings for the AMD Alchemy development boards can be found within the Linux source tree in driv- ers/mtd/maps/. For the examples above, the actual filenames are db1550-flash.c and alchemy-flash.c, respectively. These MTD mappings divide the Flash memory into separate regions of differing size as shown in Figure 3-1. These regions become separate MTD partitions when Linux is run. In the case of the AMD Alchemy development boards, the regions are arranged as follows. 3 MB mtdblock2 Kernel image (raw binary) 1 MB mtdblock1 YAMON (raw binary) Size -4 MB mtdblock0 Root file system (JFFS2) Figure 3-1. MTD Partition Mapping Therefore, on a DBAu1200 development board, which has 64 MB of Flash, the lower 60 MB of Flash is available for use as the root file system, while the upper 4 MB is reserved for the YAMON boot loader and a 3 MB binary kernel image. Note, however, that YAMON uses the upper 256 kB of Flash to store its environment variables, so this space is not made acces- sible by MTD. 3.2 Obtain MTD Tools In order to build a JFFS2 image, the mkfs.jffs2 tool must be built from the MTD toolkit. Obtain the MTD source directly from the project’s CVS server: # cvs -d :pserver:[email protected]:/home/cvs login password: anoncvs # cvs -d :pserver:[email protected]:/home/cvs co mtd Alternately, obtain daily snapshots from ftp://ftp.uk.linux.org/pub/people/dwmw2/mtd/cvs/. Once the MTD source has been obtained, build the mkfs.jffs2 utility (the actual drivers have already been incorporated into the AMD Alchemy Linux kernel source tree, and need not be built): # cd mtd/util # make mkfs.jffs2 Once the binary is built, it may be copied to any location within the PATH. # cp mkfs.jffs2 /usr/sbin 3.2.1 Prepare Root File System Before booting the root file system, ensure the /etc/fstab file is configured to use an MTD-based root file system. Create or replace the existing entry for the root mount point (/) in the /etc/fstab file with an entry similar to the following: /dev/mtdblock0 / jffs2 defaults,sync,noatime 1 1 Unless using devfs or udev, MTD device nodes must also be added to the /dev/ directory of the root file system. This can be done using the MAKEDEV script included in the MontaVista root file system: # cd rootfs/dev # ./MAKEDEV mtd # ./MAKEDEV mtdblock AMD Alchemy™ Processors Building a Root File System for Linux® Incorporating Memroy Technology Devices 3 Application Note 40755A - May 2006 - Confidential 3.3 Create JFFS2 Image Once the mkfs.jffs2 tool has been built, it can be used to build a JFFS2 binary image out of the root file system created in Section 2.0 on page 1. The following example creates an image for a DBAu1200 development board from a file system located in the directory “rootfs”. # mkfs.jffs2 –p0x3C00000 –drootfs –orootfs.jffs2 –l –q –v The image created, rootfs.jffs2, will be 60 MB (0x3C00000 bytes), which is the size of the available MTD partition as dis- cussed in Section 3.1 beginning on page 2.
Load more

Recommended publications
  • LSP 1.20 Davinci Linux NOR Flash Device Driver
    LSP 1.20 DaVinci Linux NOR Flash Driver User's Guide Literature Number: SPRUF10 April 2008 2 SPRUF10–April 2008 Submit Documentation Feedback Contents 1 Overview............................................................................................................................. 5 1.1 System Requirements .................................................................................................... 5 1.2 Design Overview .......................................................................................................... 6 2 Installation Guide................................................................................................................. 7 2.1 List of Installable Components .......................................................................................... 7 2.2 Component Folder ........................................................................................................ 7 2.3 Development Tools ....................................................................................................... 7 2.4 Build......................................................................................................................... 8 2.5 Steps to Load/Unload the NOR Flash Driver.......................................................................... 8 3 NOR Flash Driver Porting...................................................................................................... 9 3.1 Customizing the NOR-flash partitions .................................................................................
    [Show full text]
  • DASH: Database Shadowing for Mobile DBMS
    DASH: Database Shadowing for Mobile DBMS Youjip Won1 Sundoo Kim2 Juseong Yun2 Dam Quang Tuan2 Jiwon Seo2 1KAIST, Daejeon, Korea 2Hanyang University, Seoul, Korea [email protected] [email protected] ABSTRACT 1. INTRODUCTION In this work, we propose Database Shadowing, or DASH, Crash recovery is a vital part of DBMS design. Algorithms which is a new crash recovery technique for SQLite DBMS. for crash recovery range from naive full-file shadowing [15] DASH is a hybrid mixture of classical shadow paging and to the sophisticated ARIES protocol [38]. Most enterprise logging. DASH addresses four major issues in the current DBMS's, e.g., IBM DB2, Informix, Micrsoft SQL and Oracle SQLite journal modes: the performance and write amplifi- 8, use ARIES or its variants for efficient concurrency control. cation issues of the rollback mode and the storage space re- SQLite is one of the most widely used DBMS's. It is quirement and tail latency issues of the WAL mode. DASH deployed on nearly all computing platform such as smart- exploits two unique characteristics of SQLite: the database phones (e.g, Android, Tizen, Firefox, and iPhone [52]), dis- files are small and the transactions are entirely serialized. tributed filesystems (e.g., Ceph [58] and Gluster filesys- DASH consists of three key ingredients Aggregate Update, tem [1]), wearable devices (e.g., smart watch [4, 21]), and Atomic Exchange and Version Reset. Aggregate Update elim- automobiles [19, 55]. As a library-based embedded DBMS, inates the redundant write overhead and the requirement to SQLite deliberately adopts a basic transaction management maintain multiple snapshots both of which are inherent in and crash recovery scheme.
    [Show full text]
  • 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.
    [Show full text]
  • Redbooks Paper Linux on IBM Zseries and S/390
    Redbooks Paper Simon Williams Linux on IBM zSeries and S/390: TCP/IP Broadcast on z/VM Guest LAN Preface This Redpaper provides information to help readers plan for and exploit Internet Protocol (IP) broadcast support that was made available to z/VM Guest LAN environments with the introduction of the z/VM 4.3 Operating System. Using IP broadcast support, Linux guests can for the first time use DHCP to lease an IP address dynamically from a DHCP server in a z/VM Guest LAN environment. This frees the administrator from the previous method of having to hardcode an IP address for every Linux guest in the system. This new feature enables easier deployment and administration of large-scale Linux environments. Objectives The objectives of this paper are to: Review the z/VM Guest LAN environment Explain IP broadcast Introduce the Dynamic Host Configuration Protocol (DHCP) Explain how DHCP works in a z/VM Guest LAN Describe how to implement DHCP in a z/VM Guest LAN environment © Copyright IBM Corp. 2003. All rights reserved. ibm.com/redbooks 1 z/VM Guest LAN Attention: While broadcast support for z/VM Guest LANs was announced with the base z/VM 4.3 operating system, the user must apply the PTF for APAR VM63172. This APAR resolves several issues which have been found to inhibit the use of DHCP by Linux-based applications running over the z/VM Guest LAN (in simulated QDIO mode). Introduction Prior to z/VM 4.2, virtual connectivity options for connecting one or more virtual machines (VM guests) was limited to virtual channel-to-channel adapters (CTCA) and the Inter-User Communications Vehicle (IUCV) facility.
    [Show full text]
  • Ext4 File System and Crash Consistency
    1 Ext4 file system and crash consistency Changwoo Min 2 Summary of last lectures • Tools: building, exploring, and debugging Linux kernel • Core kernel infrastructure • Process management & scheduling • Interrupt & interrupt handler • Kernel synchronization • Memory management • Virtual file system • Page cache and page fault 3 Today: ext4 file system and crash consistency • File system in Linux kernel • Design considerations of a file system • History of file system • On-disk structure of Ext4 • File operations • Crash consistency 4 File system in Linux kernel User space application (ex: cp) User-space Syscalls: open, read, write, etc. Kernel-space VFS: Virtual File System Filesystems ext4 FAT32 JFFS2 Block layer Hardware Embedded Hard disk USB drive flash 5 What is a file system fundamentally? int main(int argc, char *argv[]) { int fd; char buffer[4096]; struct stat_buf; DIR *dir; struct dirent *entry; /* 1. Path name -> inode mapping */ fd = open("/home/lkp/hello.c" , O_RDONLY); /* 2. File offset -> disk block address mapping */ pread(fd, buffer, sizeof(buffer), 0); /* 3. File meta data operation */ fstat(fd, &stat_buf); printf("file size = %d\n", stat_buf.st_size); /* 4. Directory operation */ dir = opendir("/home"); entry = readdir(dir); printf("dir = %s\n", entry->d_name); return 0; } 6 Why do we care EXT4 file system? • Most widely-deployed file system • Default file system of major Linux distributions • File system used in Google data center • Default file system of Android kernel • Follows the traditional file system design 7 History of file system design 8 UFS (Unix File System) • The original UNIX file system • Design by Dennis Ritche and Ken Thompson (1974) • The first Linux file system (ext) and Minix FS has a similar layout 9 UFS (Unix File System) • Performance problem of UFS (and the first Linux file system) • Especially, long seek time between an inode and data block 10 FFS (Fast File System) • The file system of BSD UNIX • Designed by Marshall Kirk McKusick, et al.
    [Show full text]
  • O'reilly Linux Kernel in a Nutshell.Pdf
    ,title.4229 Page i Friday, December 1, 2006 9:52 AM LINUX KERNEL IN A NUTSHELL ,title.4229 Page ii Friday, December 1, 2006 9:52 AM Other Linux resources from O’Reilly Related titles Building Embedded Linux Running Linux Systems Understanding Linux Linux Device Drivers Network Internals Linux in a Nutshell Understanding the Linux Linux Pocket Guide Kernel Linux Books linux.oreilly.com is a complete catalog of O’Reilly’s Resource Center books on Linux and Unix and related technologies, in- cluding sample chapters and code examples. Conferences O’Reilly brings diverse innovators together to nurture the ideas that spark revolutionary industries. We spe- cialize in documenting the latest tools and systems, translating the innovator’s knowledge into useful skills for those in the trenches. Visit conferences.oreilly.com for our upcoming events. Safari Bookshelf (safari.oreilly.com) is the premier on- line reference library for programmers and IT professionals. Conduct searches across more than 1,000 books. Subscribers can zero in on answers to time-critical questions in a matter of seconds. Read the books on your Bookshelf from cover to cover or sim- ply flip to the page you need. Try it today for free. ,title.4229 Page iii Friday, December 1, 2006 9:52 AM LINUX KERNEL IN A NUTSHELL Greg Kroah-Hartman Beijing • Cambridge • Farnham • Köln • Paris • Sebastopol • Taipei • Tokyo ,LKNSTOC.fm.8428 Page v Friday, December 1, 2006 9:55 AM Chapter 1 Table of Contents Preface . ix Part I. Building the Kernel 1. Introduction . 3 Using This Book 4 2. Requirements for Building and Using the Kernel .
    [Show full text]
  • CS 152: Computer Systems Architecture Storage Technologies
    CS 152: Computer Systems Architecture Storage Technologies Sang-Woo Jun Winter 2019 Storage Used To be a Secondary Concern Typically, storage was not a first order citizen of a computer system o As alluded to by its name “secondary storage” o Its job was to load programs and data to memory, and disappear o Most applications only worked with CPU and system memory (DRAM) o Extreme applications like DBMSs were the exception Because conventional secondary storage was very slow o Things are changing! Some (Pre)History Magnetic core memory Rope memory (ROM) 1960’s Drum memory 1950~1970s 72 KiB per cubic foot! 100s of KiB (1024 bits in photo) Hand-woven to program the 1950’s Apollo guidance computer Photos from Wikipedia Some (More Recent) History Floppy disk drives 1970’s~2000’s 100 KiBs to 1.44 MiB Hard disk drives 1950’s to present MBs to TBs Photos from Wikipedia Some (Current) History Solid State Drives Non-Volatile Memory 2000’s to present 2010’s to present GB to TBs GBs Hard Disk Drives Dominant storage medium for the longest time o Still the largest capacity share Data organized into multiple magnetic platters o Mechanical head needs to move to where data is, to read it o Good sequential access, terrible random access • 100s of MB/s sequential, maybe 1 MB/s 4 KB random o Time for the head to move to the right location (“seek time”) may be ms long • 1000,000s of cycles! Typically “ATA” (Including IDE and EIDE), and later “SATA” interfaces o Connected via “South bridge” chipset Ding Yuan, “Operating Systems ECE344 Lecture 11: File
    [Show full text]
  • Filesystem Considerations for Embedded Devices ELC2015 03/25/15
    Filesystem considerations for embedded devices ELC2015 03/25/15 Tristan Lelong Senior embedded software engineer Filesystem considerations ABSTRACT The goal of this presentation is to answer a question asked by several customers: which filesystem should you use within your embedded design’s eMMC/SDCard? These storage devices use a standard block interface, compatible with traditional filesystems, but constraints are not those of desktop PC environments. EXT2/3/4, BTRFS, F2FS are the first of many solutions which come to mind, but how do they all compare? Typical queries include performance, longevity, tools availability, support, and power loss robustness. This presentation will not dive into implementation details but will instead summarize provided answers with the help of various figures and meaningful test results. 2 TABLE OF CONTENTS 1. Introduction 2. Block devices 3. Available filesystems 4. Performances 5. Tools 6. Reliability 7. Conclusion Filesystem considerations ABOUT THE AUTHOR • Tristan Lelong • Embedded software engineer @ Adeneo Embedded • French, living in the Pacific northwest • Embedded software, free software, and Linux kernel enthusiast. 4 Introduction Filesystem considerations Introduction INTRODUCTION More and more embedded designs rely on smart memory chips rather than bare NAND or NOR. This presentation will start by describing: • Some context to help understand the differences between NAND and MMC • Some typical requirements found in embedded devices designs • Potential filesystems to use on MMC devices 6 Filesystem considerations Introduction INTRODUCTION Focus will then move to block filesystems. How they are supported, what feature do they advertise. To help understand how they compare, we will present some benchmarks and comparisons regarding: • Tools • Reliability • Performances 7 Block devices Filesystem considerations Block devices MMC, EMMC, SD CARD Vocabulary: • MMC: MultiMediaCard is a memory card unveiled in 1997 by SanDisk and Siemens based on NAND flash memory.
    [Show full text]
  • Ensuring Data Confidentiality Via Plausibly Deniable Encryption and Secure Deletion – a Survey Qionglu Zhang1,2,3, Shijie Jia1,2*, Bing Chang4 and Bo Chen5*
    Zhang et al. Cybersecurity (2018) 1:1 Cybersecurity https://doi.org/10.1186/s42400-018-0005-8 SURVEY Open Access Ensuring data confidentiality via plausibly deniable encryption and secure deletion – a survey Qionglu Zhang1,2,3, Shijie Jia1,2*, Bing Chang4 and Bo Chen5* Abstract Ensuring confidentiality of sensitive data is of paramount importance, since data leakage may not only endanger data owners’ privacy, but also ruin reputation of businesses as well as violate various regulations like HIPPA and Sarbanes-Oxley Act. To provide confidentiality guarantee, the data should be protected when they are preserved in the personal computing devices (i.e., confidentiality during their lifetime); and also, they should be rendered irrecoverable after they are removed from the devices (i.e., confidentiality after their lifetime). Encryption and secure deletion are used to ensure data confidentiality during and after their lifetime, respectively. This work aims to perform a thorough literature review on the techniques being used to protect confidentiality of the data in personal computing devices, including both encryption and secure deletion. Especially for encryption, we mainly focus on the novel plausibly deniable encryption (PDE), which can ensure data confidentiality against both a coercive (i.e., the attacker can coerce the data owner for the decryption key) and a non-coercive attacker. Keywords: Data confidentiality, Plausibly deniable encryption, Secure deletion Introduction Spahr LLP: State and local governments move swiftly to Modern computing devices (e.g., desktops, laptops, smart sue equifax 2017); Third, it will directly violate regulations phones, tablets, wearable devices) are increasingly used like HIPAA (Congress 1996), Gramm-Leach-Bliley Act to process sensitive or even mission critical data.
    [Show full text]
  • Recursive Updates in Copy-On-Write File Systems - Modeling and Analysis
    2342 JOURNAL OF COMPUTERS, VOL. 9, NO. 10, OCTOBER 2014 Recursive Updates in Copy-on-write File Systems - Modeling and Analysis Jie Chen*, Jun Wang†, Zhihu Tan*, Changsheng Xie* *School of Computer Science and Technology Huazhong University of Science and Technology, China *Wuhan National Laboratory for Optoelectronics, Wuhan, Hubei 430074, China [email protected], {stan, cs_xie}@hust.edu.cn †Dept. of Electrical Engineering and Computer Science University of Central Florida, Orlando, Florida 32826, USA [email protected] Abstract—Copy-On-Write (COW) is a powerful technique recursive update. Recursive updates can lead to several for data protection in file systems. Unfortunately, it side effects to a storage system, such as write introduces a recursively updating problem, which leads to a amplification (also can be referred as additional writes) side effect of write amplification. Studying the behaviors of [4], I/O pattern alternation [5], and performance write amplification is important for designing, choosing and degradation [6]. This paper focuses on the side effects of optimizing the next generation file systems. However, there are many difficulties for evaluation due to the complexity of write amplification. file systems. To solve this problem, we proposed a typical Studying the behaviors of write amplification is COW file system model based on BTRFS, verified its important for designing, choosing, and optimizing the correctness through carefully designed experiments. By next generation file systems, especially when the file analyzing this model, we found that write amplification is systems uses a flash-memory-based underlying storage greatly affected by the distributions of files being accessed, system under online transaction processing (OLTP) which varies from 1.1x to 4.2x.
    [Show full text]
  • F2punifycr: a Flash-Friendly Persistent Burst-Buffer File System
    F2PUnifyCR: A Flash-friendly Persistent Burst-Buffer File System ThanOS Department of Computer Science Florida State University Tallahassee, United States I. ABSTRACT manifold depending on the workloads it is handling for With the increased amount of supercomputing power, applications. In order to leverage the capabilities of burst it is now possible to work with large scale data that buffers to the utmost level, it is very important to have a pose a continuous opportunity for exascale computing standardized software interface across systems. It has to that puts immense pressure on underlying persistent data deal with an immense amount of data during the runtime storage. Burst buffers, a distributed array of node-local of the applications. persistent flash storage devices deployed on most of Using node-local burst buffer can achieve scalable the leardership supercomputers, are means to efficiently write bandwidth as it lets each process write to the handling the bursty I/O invoked through cutting-edge local flash drive, but when the files are shared across scientific applications. In order to manage these burst many processes, it puts the management of metadata buffers, many ephemeral user level file system solutions, and object data of the files under huge challenge. In like UnifyCR, are present in the research and industry order to handle all the challenges posed by the bursty arena. Because of the intrinsic nature of the flash devices and random I/O requests by the Scientific Applica- due to background processing overhead, like Garbage tions running on leadership Supercomputing clusters, Collection, peak write bandwidth is hard to get.
    [Show full text]
  • ANDROID PRIVACY THROUGH ENCRYPTION by DANIEL
    ANDROID PRIVACY THROUGH ENCRYPTION by DANIEL DEFREEZ A THESIS Presented to the Department of Computer Science in partial fullfillment of the requirements for the degree of Master of Science in Mathematics and Computer Science Ashland, Oregon May 2012 ii APPROVAL PAGE “Android Privacy Through Encryption,” a thesis prepared by Daniel DeFreez in partial fulfillment of the requirements for the Master of Science in Mathematics and Computer Science. This project has been approved and accepted by: Dr. Lynn Ackler, Chair of the Examining Committee Date Pete Nordquist, Committee Member Date Hart Wilson, Committee Member Date Daniel DeFreez c 2012 iii ABSTRACT OF THESIS ANDROID PRIVACY THROUGH ENCRYPTION By Daniel DeFreez This thesis explores the field of Android forensics in relation to a person’s right to privacy. As the field of mobile forensics becomes increasingly sophisticated, it is clear that bypassing common privacy measures, such as disk encryption, will become routine. A new keying method for eCryptfs is proposed that could significantly mitigate memory attacks against encrypted file systems. It is shown how eCryptfs could be modified to implement this keying method on an Android device. iv ACKNOWLEDGMENTS I would like to thank Dr. Lynn Ackler for introducing me to the vast world of computer security and forensics, cultivating a healthy paranoia, and for being a truly excellent teacher. Dr. Dan Harvey, Pete Nordquist, and Hart Wilson provided helpful feedback during the preparation of this thesis, for which I thank them. I am deeply indebted to my friends and colleagues Brandon Kester, Andrew Krug, Adam Mashinchi, Jeff McJunkin, and Stephen Perkins, for their enthusiastic interest in the forensics and security fields, insightful comments, love of free software, and encouraging words.
    [Show full text]