DOCSLIB.ORG

Lecture 23: Filesystems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Lecture 23: Filesystems Lecture 23: Filesystems Fall 2018 Jason Tang Slides based upon Operating System Concept slides, http://codex.cs.yale.edu/avi/os-book/OS9/slide-dir/index.html Copyright Silberschatz, Galvin, and Gagne, 2013 "1 Topics • File Organization! • Filesystem Structure! • Filesystem Implementation "2 Files • File: logical storage unit, collection of related information! • File consists of actual stored contents plus file attributes (so-called metadata)! • Metadata kept in directory structure (usually not with file data) Attribute Usage Name Human readable symbolic name Identifier Unique numeric identifier Size Current file size Time, data, user Data for protection, security and usage identification monitoring "3 Higher-Order Structures • Directory: collection of nodes containing information about all files! • Both directory structure and files reside on disk! • Partitions: subdivision of disks; also known as a slice! • Volume: any entity containing a file system! • May be subset of a device, or set of devices (as per a RAID)! • Tracks file system information in directories "4 Typical File System Organization "5 Directory Operations • Search for a file: find a particular file, or find files whose names match a pattern! • Create a file and delete files! • List a directory: obtain list of all files in a directory, including file metadata! • Rename file: not supported in all OSes "6 Directory Organization • Directory organized logically to obtain:! • E$ciency: locating a file quickly! • Naming: convenient to users! • Multiple users can have same name for di%erent files! • Same file can have multiple names! • Grouping: logical grouping of files by properties (e.g., all Java programs) "7 Single-Level Directory • Single directory, shared by all users! • Su%ers from naming problem! • Su%ers from grouping problem "8 Tree-Structured Directories "9 Tree-Structured Directories • E$cient searching! • Grouping capability! • Absolute or relative path name! • Creating a new file is done in current working directory! • When attempting to delete a non-empty directory, either forbid operation or recursively delete all contents within "10 Acyclic-Graph Directories • Multiple names for same file (aliasing)! • When deleting a file, either remove all pointers to file, or just remove link and actually delete file when its reference count reaches 0 "11 Directory Implementation • Linear list of file names with pointer to data blocks! • Simple to program, requires least amount of space! • Linear search time! • Could keep file names ordered alphabetically via linked list or B+ tree! • Hash table to decrease directory search time! • Collision when two file names hash to same location "12 Filesystem Structure • Filesystem: provides user space interface to secondary storage (HDDs and SDDs)! • Maps logical files to physical locations on disk! • E$cient and convenient access to disk by allowing data to be stored, located, and retrieved easily! • Filesystems are optimized for specific use cases; there is no such thing as a “universal filesystem” "13 Modern Filesystems • Windows: FAT32, NTFS! • Linux: Btrfs, Ext4, ReiserFS, XFS, ZFS! • Mac OS: HFS+, UFS, APFS! • Optical disks: ISO 9660, UDF! • Optimized for SSDs (without integrated wear controllers): JFFS, UBIFS! • Network-based: CEPH, Lustre, NFS "14 Filesystem Constraints • HDDs and SSDs require I/O transfers performed in blocks of sectors (often in increments of 512 bytes)! • For HDDs, disk provides in-place rewrite and random access! • For SSDs, filesystem must take into account wear leveling and sector erase sizes! • Filesystems are often fault-tolerant! • Example: a small scratch on a DVD should not prevent access to data! • Filesystem driver usually organized into layers "15 Layered Filesystem • I/O control layer manage devices! • Example: given command “read drive 1, cylinder 72, track 2, sector 10, into memory location 1060”, outputs low-level hardware specific commands to device controller! • Base filesystem layer tracks blocks and their physical locations; manages bu%ers and caches! • Example: given command “retrieve block 123”, outputs “drive 1, cylinder 72, track 2, sector 10” "16 Layered Filesystem • File organization layer uses file allocation algorithm(s) to reserve logical blocks for files! • Translates logical block numbers (starting with 0) to physical location! • Logical filesystem manages metadata information! • Directory management! • Translates file name into file control block (FCB)! • Contains permissions, last modified time, etc "17 Filesystem Implementation • Boot Control Block: contains data needed by system to boot OS stored on that volume! • Volume Control Block (also known as superblock or master file table): contains details, such as number of blocks, number of free blocks, block size, and mapping of blocks in use! • Directory Structure: contains names and inode numbers of items within (files and subdirectories) "18 Inodes • For many filesystems, each file has an inode (index node), identified as a unique unsigned integer number! • Inodes stored on disk and contains file metadata! • Files can have multiple names, via hard links! • When file is moved to another directory within same device, its inode number stays the same "19 Opening Files • Kernel has a system-wide open file table! • When a process opens a file, kernel searches system-wide table! • If file already opened, a per-process open file entry created pointing to existing entry (referenced by user space via a file handle or file descriptor)! • Otherwise, kernel copies contents of inode from disk into a new entry "20 File Operations • User space reads/writes using its file handle! • Kernel tracks number of references to each entry within system-wide table! • Count decremented when process calls close() or exits! • When count reaches 0, kernel removes entry from table "21 Mounting Filesystems • When kernel first accesses a filesystem, it must mount it to check for consistency! • Checks that all metadata are correct! • Verifies all checksums! • Mount point: location within filesystem that user space may access new filesystem! • Example: When placing a DVD into a DVD drive, Windows will automatically mount the disc’s UDF’s filesystem at the D: mount point "22 Linux Virtual Filesystem • In Linux, all files are accessed through the virtual filesystem (VFS), an in- kernel abstraction layer! • Not to be confused with virtual files (like those in /proc or /sys)! • Allows same system call interface to be used for di%erent filesystem types! • Separates filesystem generic operations from implementation details! • Implementation can be one of many filesystem types, or even reach across a network for network-based filesystems "23 Linux Virtual Filesystem "24 Linux Virtual Filesystem • Every Linux filesystem registers itself as a series of function pointer table! • struct super_operations: functions to allocate blocks, perform consistency checks, and other operations involving superblocks! • struct inode_operations: functions to manipulate inodes, lookup inodes within directories, update inode access times! • struct file_operations: handles actual reading and writing of files to secondary storage! • When a file is opened, its in-kernel handle’s function pointer tables are set to underlying filesystem’s function pointer tables "25.
Load more

Recommended publications
  • 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.
    [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]
  • 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]
  • Elinos Product Overview
    SYSGO Product Overview ELinOS 7 Industrial Grade Linux ELinOS is a SYSGO Linux distribution to help developers save time and effort by focusing on their application. Our Industrial Grade Linux with user-friendly IDE goes along with the best selection of software packages to meet our cog linux Qt LOCK customers needs, and with the comfort of world-class technical support. ELinOS now includes Docker support Feature LTS Qt Open SSH Configurator Kernel embedded Open VPN in order to isolate applications running on the same system. laptop Q Bug Shield-Virus Docker Eclipse-based QEMU-based Application Integrated Docker IDE HW Emulators Debugging Firewall Support ELINOS FEATURES MANAGING EMBEDDED LINUX VERSATILITY • Industrial Grade Creating an Embedded Linux based system is like solving a puzzle and putting • Eclipse-based IDE for embedded the right pieces together. This requires a deep knowledge of Linux’s versatility Systems (CODEO) and takes time for the selection of components, development of Board Support • Multiple Linux kernel versions Packages and drivers, and testing of the whole system – not only for newcomers. incl. Kernel 4.19 LTS with real-time enhancements With ELinOS, SYSGO offers an ‘out-of-the-box’ experience which allows to focus • Quick and easy target on the development of competitive applications itself. ELinOS incorporates the system configuration appropriate tools, such as a feature configurator to help you build the system and • Hardware Emulation (QEMU) boost your project success, including a graphical configuration front-end with a • Extensive file system support built-in integrity validation. • Application debugging • Target analysis APPLICATION & CONFIGURATION ENVIRONMENT • Runs out-of-the-box on PikeOS • Validated and tested for In addition to standard tools, remote debugging, target system monitoring and PowerPC, x86, ARM timing behaviour analyses are essential for application development.
    [Show 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.
    [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]
  • 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]
  • Zálohuj S BTRFS!
    Zalohuj´ s BTRFS! Bc . Josef Jebavy´ www.josefjebavy.cz 3. 11. 2018 Bc . Josef Jebavy´ Zalohuj´ s BTRFS! whoami Bc. Josef Jebavy´ Linux admin Vyvoj´ a´rˇ software Clenˇ Geeklab a prˇ´ıznivec OpenAlt Bc . Josef Jebavy´ Zalohuj´ s BTRFS! Osnova 1 Zalohov´ an´ ´ı 2 Filesystemy´ Filesystemy´ 3 Btrfs 4 RAID 5 Btrfs vsudeˇ 6 Fstab 7 Grub 8 UEFI 9 Snapshot Create Delete 10 Informace filesystem´ u˚ 11 Zkusenostiˇ 12 Odkazy 13 Dotazy, skolenˇ ´ı, kontakt Bc . Josef Jebavy´ Zalohuj´ s BTRFS! Bc . Josef Jebavy´ Zalohuj´ s BTRFS! Ulo´ znˇ a´ media´ Rotacnˇ ´ı SSD (TRIM) CD/DVD Pasky´ Bc . Josef Jebavy´ Zalohuj´ s BTRFS! cetnostˇ zalohov´ an´ ´ı, archivace lokace medium nastroje´ kontrola, obnoven´ı Bc . Josef Jebavy´ Zalohuj´ s BTRFS! Filesystem´ Co je filesystem?´ Bc . Josef Jebavy´ Zalohuj´ s BTRFS! Filesystemy:´ FAT32, NTFS (1993) ext3(2001),ext3(2004), RaiseFS, JFS, HFS (1985), HFS+ (1998, b-trees) ZFS (2005) JFFS, UBIFS BTRFS(2009) Bc . Josef Jebavy´ Zalohuj´ s BTRFS! Vlastnosti Aneb procˇ pouzˇ´ıvat BTRFS: B-tree file system vyvoj´ od roku 2007 copy-on-write kontroln´ı souctyˇ RAID 0,1 komprese snapshoty-zalohov´ an´ ´ı send/receive zmenyˇ za chodu obdoba ZFS - licecnˇ ´ı nekompatibilita TRIM Bc . Josef Jebavy´ Zalohuj´ s BTRFS! Zat´ım ve vyvoji´ RAID 5,6 Sifrovˇ an´ ´ı Bc . Josef Jebavy´ Zalohuj´ s BTRFS! Podpora Podporovane´ platformy Linux x86 i ARM atd. Prˇ´ımo soucˇast´ linuxoveho´ jadra´ - od verze 2.6.29-rc1 Bc . Josef Jebavy´ Zalohuj´ s BTRFS! Zkusenostiˇ Ja´ od roku 2013 Btrfs btrfs-progs (jul 2018 v4.17) Odlisnˇ e´ Hodneˇ moznostˇ ´ı Manual´ Bc .
    [Show full text]
  • A Brief Introduction to the Design of UBIFS Document Version 0.1 by Adrian Hunter 27.3.2008
    A Brief Introduction to the Design of UBIFS Document version 0.1 by Adrian Hunter 27.3.2008 A file system developed for flash memory requires out-of-place updates . This is because flash memory must be erased before it can be written to, and it can typically only be written once before needing to be erased again. If eraseblocks were small and could be erased quickly, then they could be treated the same as disk sectors, however that is not the case. To read an entire eraseblock, erase it, and write back updated data typically takes 100 times longer than simply writing the updated data to a different eraseblock that has already been erased. In other words, for small updates, in-place updates can take 100 times longer than out-of-place updates. Out-of-place updating requires garbage collection. As data is updated out-of-place, eraseblocks begin to contain a mixture of valid data and data which has become obsolete because it has been updated some place else. Eventually, the file system will run out of empty eraseblocks, so that every single eraseblock contains a mixture of valid data and obsolete data. In order to write new data somewhere, one of the eraseblocks must be emptied so that it can be erased and reused. The process of identifying an eraseblock with a lot of obsolete data, and moving the valid data to another eraseblock, is called garbage collection. Garbage collection suggests the benefits of node-structure. In order to garbage collect an eraseblock, a file system must be able to identify the data that is stored there.
    [Show full text]