DOCSLIB.ORG

Using an Ez80 Flash Memory File System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Application Note Using an eZ80® Flash Memory File System AN017303-0908 Abstract you have the performance necessary to execute complex applications quickly and efficiently. Com- This Application Note demonstrates a method for bining Flash and SRAM, eZ80Acclaim! devices creating a file system that can be stored within the provide the memory required to implement com- external Flash memory space connected to Zilog’s munication protocol stacks and achieve flexibility eZ80® microprocessors. This file system is used when performing in-system updates of application with the Zilog TCP/IP (ZTP) Software Suite that firmware. runs on the XINU operating system. The Applica- tions Programming Interface (API) functions The eZ80Acclaim! Flash MCU can operate in full developed for this file system can be used to 24-bit linear mode addressing 16 MB without a develop applications with minimum effort. An Memory Management Unit (MMU). Additionally, eZ80 Development Module features 1 MB of Flash support for the Z80®-compatible mode allows Z80/ Memory, which is large enough to accommodate Z180 legacy code execution within multiple 64 KB the application data and Flash file system storage. memory blocks with minimum modification. With an external bus supporting eZ80, Z80, Intel, and The file system proposed in this Application Note Motorola bus modes and a rich set of serial com- cannot be used for HTTP implementation. HTTP munications peripherals, you have several options uses sequentially stored files and does not support when interfacing to external devices. the file system API discussed in this Application Note. Some of the applications suitable for eZ80Acclaim! devices include vending machines, Note: The source code file associated with point-of-sale (POS) terminals, security systems, this application note, AN0173- automation, communications, industrial control SC01.zip is available for down- and facility monitoring, and remote control. load at www.zilog.com. eZ80® General-Purpose Product Overview Microprocessors The Application Note supports the eZ80 family of The eZ80 has revolutionized the communication microprocessing devices, which includes eZ80 industry. It executes Zilog’s Z80 code four times microprocessors and eZ80Acclaim!® Flash micro- faster at the same clock speed of traditional Z80s controllers unit (MCU). Both product lines are and can operate at frequencies up to 50 MHz. briefly described in this section. Unlike most 8-bit microprocessors, which can only address 64 KB, the eZ80 can address 16 MB eZ80Acclaim! Flash MCU without a MMU. eZ80Acclaim! on-chip Flash MCU are an excep- Designed with over 25 years of experience with the tional value for designing high performance, 8-bit Z80, this microprocessor is best suited for embed- MCU-based systems. With speeds up to 50 MHz ded internet appliances, industrial control, automa- and an on-chip Ethernet MAC (for eZ80F91 only), tion, web management, modem controller, Copyright ©2008 by Zilog®, Inc. All rights reserved. www.zilog.com Using an eZ80® Flash Memory File System electronic games, and personal digital assistant types, there are certain specific terms used when (PDA) applications. describing nearly all file systems. First, the term file is used to define a file system unit, which is Discussion considered to be a sequence of records with the same structure or type. Second, the term disk is File systems offer a common way to store data of used to define a storage unit that contains a set of any type, often over an extended period of time. files. They are useful for accumulating and transferring data between different types of operating environ- In the evolution of file systems, APIs are gaining ments and devices. This section discusses the con- acceptance relatively recently as a standard for siderations for designing a file system for an adding modular functionality to file systems. Such embedded environment. an API provides a set of C language functions to perform file create, open, read, write, and close File System Overview operations for file manipulation. Widely-known examples of file systems include: The file system described in this Application Note is an embedded file system for the eZ80 family of • Disk Operating System (DOS) featuring the microprocessors that includes standard set of C- FAT12 and FAT16 methods of file allocation language API functions, such as fcreate(), • 32-bit WinNT file system fopen(), fread(), fwrite(), fclose(), and others. For more details of the File System API • Compact Disk File System (CDFS) functions, see Appendix B—File System APIs on • Compact Flash file system. page 13. Each of these file systems is built for a particular hardware environment and is based on a particular Using the Embedded Flash- operating system. Typically, data is stored within a Based File System long-term storage device and loaded into short- term operating storage for processing and manipu- This section contains guidelines to be followed lation. Whenever data is processed, it is stored when using the embedded Flash-based file system within long-term storage. to develop an application. To follow the guidelines, the section first discusses the software implementa- The file system discussed in this Application Note tion for the embedded Flash-based file system. is built for the embedded hardware environment based on Zilog’s eZ80 development modules, Software Implementation which feature external Flash and RAM memory Figure 1 on page 3 displays the functional blocks spaces. Flash Memory is used for long-term stor- of the embedded Flash-based file system. The age purposes, and RAM is used as operating stor- functional blocks comprise a File System Configu- age for data processing. ration Component, File System Manipulation Functions, and the Flash Memory Interface. There are strict standards that govern how data is stored. Though storage media are offered in differ- ent types, such as magnetic media, Flash Memory, and so on, storage organization must suit media requirements and must be optimized for the work- ing environment. Despite these differing media AN017303-0908 Page 2 of 23 Using an eZ80® Flash Memory File System The file system configuration parameters consist of several entities, few are discussed below: File System Configuration File Table—The file table contains the names of Component the files represented in the current file system, along with their sizes and pointers to the data con- tained in each file. The maximum number of files File Access and in the file system is defined by the constant, API Manipulation Functions FTABLESIZE. Sector List—The sector list is the array of 16-bit values containing the sector addresses. The array Flash Memory Interface maintains a size equal to the number of sectors on the disk, NSECTORS, to be able to address each of the physical sectors. Figure 1. Functional Blocks of the Embedded Flash-Based File System Sector Data Area—The sector data area is the space used by the file data. This space is logically File System Configuration Component divided to NSECTORS blocks, called sectors. Each of the sectors maintains a size of SECTORSIZE In Figure 1, the File System Configuration Compo- bytes. nent block represents the configuration file, fileconf.h. It contains a set of configuration The init_file_system() function creates or parameters that you can modify to suit the applica- restores the file system according to the configura- tion. Table 1 lists the maximum allowable size of tion parameters’ values. An example of the the file system and the capacity of its entities as init_file_system() function can be found defined by the configuration parameters. in the fileinit.c file available in the AN0173-SC01.zip file associated with this Table 1. File System Configuration Application Note. Parameters (fileconf.h) Default File Access and Manipulation Functions Parameter Description Value In Figure 1, the File Access and Manipulation NFHANDLES The number of opened 10 Functions block represent the functions that are files used to manage the files, after the file system is created and implemented. These functions are: FTABLESIZE The number of file 32 entries in the file system fcreate(), fopen(), fread(), fwrite(), fclose(), fexists(), and ferase(), and NSECTORS The number of sectors 1000 together they form the file system API. in the disk SECTORSIZE The size of a sector in 128 Flash Memory Interface the disk The Flash Memory Interface stores the volume of VHDRSIZE Volume header size 128 data (created as a result of operations in the file system and files contained in it) into Flash Mem- ory. The Flash Memory Interface allows permanent data storage and enables you to continue working AN017303-0908 Page 3 of 23 Using an eZ80® Flash Memory File System with the file system after cycling power to the stor- age device. Any Flash Library1 can be used as a Flash Memory FILE STRUCTURE Interface. The Flash Loader application available NAME SIZE START with the ZDS II–IDE is an example that uses a Flash Memory Interface. Yet another example is the eZ80® Remote Access Application Note (AN0134) available on the www.zilog.com. SECTOR TABLE SECTOR 1 SECTOR 2 File System Data Structure This section discusses the file_entry data structure used for each structural units that com- pose the embedded Flash-based file system. SECTOR n END OF FILE The file_entry structure used to maintain the file table entries has the following structure: Figure 2. File Sector Chain typedef struct { The size of the file_entry structure, repre- char name[11]; // Name of the file sented by sizeof(file_entry), is 16 bytes. unsigned short start;// Starting The size of a sector number is 2 bytes (of type //sector of the file unsigned short). A volume header, which contains unsigned int size;// Size of file in the volume parameters, must also be included in //bytes the structure. } file_entry; Table 2 lists the embedded Flash-based file system The start variable contains the ordinal number representation with a 16-byte file_entry struc- of the first sector owned by the file.
Recommended publications
  • Development of a Verified Flash File System ⋆

    Development of a Verified Flash File System ⋆

    Development of a Verified Flash File System ? Gerhard Schellhorn, Gidon Ernst, J¨orgPf¨ahler,Dominik Haneberg, and Wolfgang Reif Institute for Software & Systems Engineering University of Augsburg, Germany fschellhorn,ernst,joerg.pfaehler,haneberg,reifg @informatik.uni-augsburg.de Abstract. This paper gives an overview over the development of a for- mally verified file system for flash memory. We describe our approach that is based on Abstract State Machines and incremental modular re- finement. Some of the important intermediate levels and the features they introduce are given. We report on the verification challenges addressed so far, and point to open problems and future work. We furthermore draw preliminary conclusions on the methodology and the required tool support. 1 Introduction Flaws in the design and implementation of file systems already lead to serious problems in mission-critical systems. A prominent example is the Mars Explo- ration Rover Spirit [34] that got stuck in a reset cycle. In 2013, the Mars Rover Curiosity also had a bug in its file system implementation, that triggered an au- tomatic switch to safe mode. The first incident prompted a proposal to formally verify a file system for flash memory [24,18] as a pilot project for Hoare's Grand Challenge [22]. We are developing a verified flash file system (FFS). This paper reports on our progress and discusses some of the aspects of the project. We describe parts of the design, the formal models, and proofs, pointing out challenges and solutions. The main characteristic of flash memory that guides the design is that data cannot be overwritten in place, instead space can only be reused by erasing whole blocks.
  • The Birth, Evolution and Future of Microprocessor

    The Birth, Evolution and Future of Microprocessor

    The Birth, Evolution and Future of Microprocessor Swetha Kogatam Computer Science Department San Jose State University San Jose, CA 95192 408-924-1000 [email protected] ABSTRACT timed sequence through the bus system to output devices such as The world's first microprocessor, the 4004, was co-developed by CRT Screens, networks, or printers. In some cases, the terms Busicom, a Japanese manufacturer of calculators, and Intel, a U.S. 'CPU' and 'microprocessor' are used interchangeably to denote the manufacturer of semiconductors. The basic architecture of 4004 same device. was developed in August 1969; a concrete plan for the 4004 The different ways in which microprocessors are categorized are: system was finalized in December 1969; and the first microprocessor was successfully developed in March 1971. a) CISC (Complex Instruction Set Computers) Microprocessors, which became the "technology to open up a new b) RISC (Reduced Instruction Set Computers) era," brought two outstanding impacts, "power of intelligence" and "power of computing". First, microprocessors opened up a new a) VLIW(Very Long Instruction Word Computers) "era of programming" through replacing with software, the b) Super scalar processors hardwired logic based on IC's of the former "era of logic". At the same time, microprocessors allowed young engineers access to "power of computing" for the creative development of personal 2. BIRTH OF THE MICROPROCESSOR computers and computer games, which in turn led to growth in the In 1970, Intel introduced the first dynamic RAM, which increased software industry, and paved the way to the development of high- IC memory by a factor of four.
  • Recursive Updates in Copy-On-Write File Systems - Modeling and Analysis

    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.
  • F2punifycr: a Flash-Friendly Persistent Burst-Buffer File System

    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.
  • Programmable Digital Microcircuits - a Survey with Examples of Use

    Programmable Digital Microcircuits - a Survey with Examples of Use

    - 237 - PROGRAMMABLE DIGITAL MICROCIRCUITS - A SURVEY WITH EXAMPLES OF USE C. Verkerk CERN, Geneva, Switzerland 1. Introduction For most readers the title of these lecture notes will evoke microprocessors. The fixed instruction set microprocessors are however not the only programmable digital mi• crocircuits and, although a number of pages will be dedicated to them, the aim of these notes is also to draw attention to other useful microcircuits. A complete survey of programmable circuits would fill several books and a selection had therefore to be made. The choice has rather been to treat a variety of devices than to give an in- depth treatment of a particular circuit. The selected devices have all found useful ap• plications in high-energy physics, or hold promise for future use. The microprocessor is very young : just over eleven years. An advertisement, an• nouncing a new era of integrated electronics, and which appeared in the November 15, 1971 issue of Electronics News, is generally considered its birth-certificate. The adver• tisement was for the Intel 4004 and its three support chips. The history leading to this announcement merits to be recalled. Intel, then a very young company, was working on the design of a chip-set for a high-performance calculator, for and in collaboration with a Japanese firm, Busicom. One of the Intel engineers found the Busicom design of 9 different chips too complicated and tried to find a more general and programmable solu• tion. His design, the 4004 microprocessor, was finally adapted by Busicom, and after further négociation, Intel acquired marketing rights for its new invention.
  • Architecture and Performance of Perlmutter's 35 PB Clusterstor

    Architecture and Performance of Perlmutter's 35 PB Clusterstor

    Lawrence Berkeley National Laboratory Recent Work Title Architecture and Performance of Perlmutter’s 35 PB ClusterStor E1000 All-Flash File System Permalink https://escholarship.org/uc/item/90r3s04z Authors Lockwood, Glenn K Chiusole, Alberto Gerhardt, Lisa et al. Publication Date 2021-06-18 Peer reviewed eScholarship.org Powered by the California Digital Library University of California Architecture and Performance of Perlmutter’s 35 PB ClusterStor E1000 All-Flash File System Glenn K. Lockwood, Alberto Chiusole, Lisa Gerhardt, Kirill Lozinskiy, David Paul, Nicholas J. Wright Lawrence Berkeley National Laboratory fglock, chiusole, lgerhardt, klozinskiy, dpaul, [email protected] Abstract—NERSC’s newest system, Perlmutter, features a 35 1,536 GPU nodes 16 Lustre MDSes PB all-flash Lustre file system built on HPE Cray ClusterStor 1x AMD Epyc 7763 1x AMD Epyc 7502 4x NVIDIA A100 2x Slingshot NICs E1000. We present its architecture, early performance figures, 4x Slingshot NICs Slingshot Network 24x 15.36 TB NVMe and performance considerations unique to this architecture. We 200 Gb/s demonstrate the performance of E1000 OSSes through low-level 2-level dragonfly 16 Lustre OSSes 3,072 CPU nodes Lustre tests that achieve over 90% of the theoretical bandwidth 1x AMD Epyc 7502 2x AMD Epyc 7763 2x Slingshot NICs of the SSDs at the OST and LNet levels. We also show end-to-end 1x Slingshot NICs performance for both traditional dimensions of I/O performance 24x 15.36 TB NVMe (peak bulk-synchronous bandwidth) and non-optimal workloads endemic to production computing (small, incoherent I/Os at 24 Gateway nodes 2 Arista 7804 routers 2x Slingshot NICs 400 Gb/s/port random offsets) and compare them to NERSC’s previous system, 2x 200G HCAs > 10 Tb/s routing Cori, to illustrate that Perlmutter achieves the performance of a burst buffer and the resilience of a scratch file system.
  • Introduction to Cpu

    Introduction to Cpu

    microprocessors and microcontrollers - sadri 1 INTRODUCTION TO CPU Mohammad Sadegh Sadri Session 2 Microprocessor Course Isfahan University of Technology Sep., Oct., 2010 microprocessors and microcontrollers - sadri 2 Agenda • Review of the first session • A tour of silicon world! • Basic definition of CPU • Von Neumann Architecture • Example: Basic ARM7 Architecture • A brief detailed explanation of ARM7 Architecture • Hardvard Architecture • Example: TMS320C25 DSP microprocessors and microcontrollers - sadri 3 Agenda (2) • History of CPUs • 4004 • TMS1000 • 8080 • Z80 • Am2901 • 8051 • PIC16 microprocessors and microcontrollers - sadri 4 Von Neumann Architecture • Same Memory • Program • Data • Single Bus microprocessors and microcontrollers - sadri 5 Sample : ARM7T CPU microprocessors and microcontrollers - sadri 6 Harvard Architecture • Separate memories for program and data microprocessors and microcontrollers - sadri 7 TMS320C25 DSP microprocessors and microcontrollers - sadri 8 Silicon Market Revenue Rank Rank Country of 2009/2008 Company (million Market share 2009 2008 origin changes $ USD) Intel 11 USA 32 410 -4.0% 14.1% Corporation Samsung 22 South Korea 17 496 +3.5% 7.6% Electronics Toshiba 33Semiconduc Japan 10 319 -6.9% 4.5% tors Texas 44 USA 9 617 -12.6% 4.2% Instruments STMicroelec 55 FranceItaly 8 510 -17.6% 3.7% tronics 68Qualcomm USA 6 409 -1.1% 2.8% 79Hynix South Korea 6 246 +3.7% 2.7% 812AMD USA 5 207 -4.6% 2.3% Renesas 96 Japan 5 153 -26.6% 2.2% Technology 10 7 Sony Japan 4 468 -35.7% 1.9% microprocessors and microcontrollers
  • How to Make Ez80 Code Execute Faster with Copy To

    How to Make Ez80 Code Execute Faster with Copy To

    Application Note How to Make eZ80® Code Execute Faster with Copy To RAM AN015103-1208 Abstract Two popular versions of the eZ80 offered by Zilog® are the eZ80 General-Purpose MPU This Application Note discusses how Zilog’s (eZ80L92) and the eZ80Acclaim! Family of Flash eZ80® code can execute faster by executing from MCUs, which includes the eZ80F91, eZ80F92, and RAM instead of Flash Memory, and be able to eZ80F93 devices. store the eZ80 code in Flash. With Zilog Develop- ment Studio II (ZDS II) code development tools, a eZ80L92 Features few simple changes to the project settings and the project link file are required for speedy code exe- The key features of eZ80L92 include: cution. The leddemo project that is included with the eZ80L92 device, which uses the ZDS II toolset • Single-cycle instruction fetch, high-performance, for eZ80 microprocessor unit (MPU), is used in pipelined eZ80 CPU core this Application Note as an example. However, the • Low power features including SLEEP mode, information in this document is also applicable to HALT mode, and selective peripheral power- the ZDS II toolset for eZ80Acclaim!® microcon- down control trollers unit (MCU). • Two Universal Asynchronous Receiver/Trans- Note: The source code file associated with mitters (UART) with independent baud rate gen- this application note, AN0151- erators SC01.zip is available for down- • Serial Peripheral Interface (SPI) with indepen- load at www.zilog.com. dent clock rate generator • Inter-Integrated Circuit (I2C) with independent eZ80 Overview clock rate generator eZ80 has revolutionized the communication indus- • Infrared Data Association (IrDA)-compliant try. It executes Zilog’s Z80® code four times faster infrared encoder/decoder at the same clock speed of traditional Z80s and can • New DMA-like eZ80 instructions for efficient operate at frequencies up to 50 MHz.
  • Computer Architectures an Overview

    Computer Architectures an Overview

    Computer Architectures An Overview PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 25 Feb 2012 22:35:32 UTC Contents Articles Microarchitecture 1 x86 7 PowerPC 23 IBM POWER 33 MIPS architecture 39 SPARC 57 ARM architecture 65 DEC Alpha 80 AlphaStation 92 AlphaServer 95 Very long instruction word 103 Instruction-level parallelism 107 Explicitly parallel instruction computing 108 References Article Sources and Contributors 111 Image Sources, Licenses and Contributors 113 Article Licenses License 114 Microarchitecture 1 Microarchitecture In computer engineering, microarchitecture (sometimes abbreviated to µarch or uarch), also called computer organization, is the way a given instruction set architecture (ISA) is implemented on a processor. A given ISA may be implemented with different microarchitectures.[1] Implementations might vary due to different goals of a given design or due to shifts in technology.[2] Computer architecture is the combination of microarchitecture and instruction set design. Relation to instruction set architecture The ISA is roughly the same as the programming model of a processor as seen by an assembly language programmer or compiler writer. The ISA includes the execution model, processor registers, address and data formats among other things. The Intel Core microarchitecture microarchitecture includes the constituent parts of the processor and how these interconnect and interoperate to implement the ISA. The microarchitecture of a machine is usually represented as (more or less detailed) diagrams that describe the interconnections of the various microarchitectural elements of the machine, which may be everything from single gates and registers, to complete arithmetic logic units (ALU)s and even larger elements.
  • The Z80 Microprocessor Architecture

    The Z80 Microprocessor Architecture

    DESIGN AND FABRICATION OF AN ELECTRONIC SYSTEM FOR MONITORING AND CONTROLLING TEMPERATURE, LIGHT ILLUMINANCE AND HUMIDITY IN A GREENHOUSE WYCLIFFE OBANDA NYANYA I56/0243/2003 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE (ELECTRONICS AND INSTRUMENTATION) IN THE SCHOOL OF PURE AND APPLIED SCIENCES OF KENYATTA UNIVERSITY APRIL 2010 DECLARATION I declare that the work presented in this thesis is my original work and has not been presented for a degree in any other university or for any other award. WYCLIFFE OBANDA NYANYA Signature………………………… Date………… PHYSICS DEPARTMENT KENYATTA UNIVERSITY We confirm that the candidate carried out the work reported in this thesis under our supervision. DR. PATRICK M. KARIMI Signature…………………….......... Date……...... PHYSICS DEPARTMENT KENYATTA UNIVERSITY P. O. BOX 43844-00100 GPO NAIROBI-KENYA DR. ABDALLAH S. MERENGA Signature……………………….... Date …………… PHYSICS DEPARTMENT KENYATTA UNIVERSITY P. O. BOX 43844-00100 GPO NAIROBI- KENYA ii DEDICATION This work is dedicated to my wife, Elizabeth, my daughters Sharon and Louise, my son Mark and to my late father Herbert Ambundo who would have loved to see it all. iii ACKNOWLEDGEMENTS I would like to take this opportunity to thank all my lecturers in the physics department for instilling confidence in me when pursuing this course. Special thanks go to my supervisors, Dr. P. M. Karimi and Dr. A. S. Merenga, for their guidance throughout this research. I also wish to thank my colleague John Githaiga for his useful suggestions. The technicians in the Physics department were very helpful to me during the construction of the system. I also wish to thank my wife Elizabeth Obanda for her moral support and patience.
  • UBI - Unsorted Block Images

    UBI - Unsorted Block Images

    UBI - Unsorted Block Images Thomas Gleixner Frank Haverkamp Artem Bityutskiy UBI - Unsorted Block Images by Thomas Gleixner, Frank Haverkamp, and Artem Bityutskiy Copyright © 2006 International Business Machines Corp. Revision History Revision v1.0.0 2006-06-09 Revised by: haver Release Version. Table of Contents 1. Document conventions...........................................................................................................................1 2. Introduction............................................................................................................................................2 UBI Volumes......................................................................................................................................2 Static Volumes ..........................................................................................................................2 Dynamic Volumes.....................................................................................................................3 3. MTD integration ....................................................................................................................................4 Simple partitioning.............................................................................................................................4 Complex partitioning .........................................................................................................................5 4. UBI design ..............................................................................................................................................6
  • Crossmedia File System Metafs Exploiting Performance Characteristics from Flash Storage and HDD

    Crossmedia File System Metafs Exploiting Performance Characteristics from Flash Storage and HDD

    Crossmedia File System MetaFS Exploiting Performance Characteristics from Flash Storage and HDD Bachelor Thesis Leszek Kattinger 12. November 2009 { 23. M¨arz2010 Betreuer: Prof. Dr. Thomas Ludwig Julian M. Kunkel Olga Mordvinova Leszek Kattinger Hans-Sachs-Ring 110 68199 Mannheim Hiermit erkl¨areich an Eides statt, dass ich die von mir vorgelegte Arbeit selbstst¨andig verfasst habe, dass ich die verwendeten Quellen, Internet-Quellen und Hilfsmittel vollst¨andig angegeben habe und dass ich die Stellen der Arbeit { einschließlich Tabellen, Karten und Abbildungen {, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach ent- nommen sind, auf jeden Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht habe. Mannheim, den 22. M¨arz2010 Leszek Kattinger Abstract Until recently, the decision which storage device is most suitable, in aspects of costs, capacity, performance and reliability has been an easy choice. Only hard disk devices offered requested properties. Nowadays rapid development of flash storage technology, makes these devices competitive or even more attractive. The great advantage of flash storage is, apart from lower energy consumption and insensitivity against mechanical shocks, the much lower access time. Compared with hard disks, flash devices can access data about a hundred times faster. This feature enables a significant performance benefit for random I/O operations. Unfortunately, the situation at present is that HDDs provide a much bigger capacity at considerable lower prices than flash storage devices, and this fact does not seem to be changing in the near future. Considering also the wide-spread use of HDDs, the continuing increase of storage density and the associated increase of sequential I/O performance, the incentive to use HDDs will continue.