DOCSLIB.ORG

Ext4 Block and Inode Allocator Improvements

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ext4 Block and Inode Allocator Improvements Ext4 block and inode allocator improvements Aneesh Kumar K.V Mingming Cao Jose R Santos IBM Linux Technology Center IBM Linux Technology Center IBM Linux Technology Center [email protected] [email protected] [email protected] Andreas Dilger Sun Microsystems, Inc [email protected] Abstract ext4_extent structure 95 47 31 0 File systems have conflicting needs with respect to block logical block # allocation for small and large files. Small related files physical block # should be nearby on disk to maximize disk track cache and avoid seeking. To avoid fragmentation, files that uninitialized extent flag length grow should reserve space. The new multiple block and delayed allocators for Ext4 try to satisfy these require- ext4_extent_header ext4_extent_idx ments by deferring allocation until flush time, packing eh_magic small files contiguously, and allocating large files on ei_block RAID device-aligned boundaries with reserved space eh_entries ei_leaf for growth. In this paper, we discuss the new multiple eh_max ei_leaf_hi block allocator for Ext4 and compare the same with the eh_depth ei_unused reservation-based allocation. We also discuss the perfor- eh_generation mance advantage of placing the meta-data blocks close together on disk so that meta-data intensive workloads seek less. Figure 1: Ext4 extents, header and index structures 1 Introduction modern file systems[1], and it is well-known as a way to The Ext4 file system was forked from Ext3 file system efficiently represent a large contiguous file by reducing about two years ago to address the capability and scal- the meta-data needed to address large files. Extents help ability bottleneck of the Ext3 file system. Ext3 file sys- improve the performance of sequential file read/writes tem size is hard limited to 16 TB on x86 architecture, since extents are a significantly smaller amount of meta- as a consequence of 32-bit block numbers. This limit data to be written to describe contiguous blocks, thus re- has already been reached in the enterprise world. With ducing the file system overhead. It also greatly reduces the disk capacity doubling every year and with increas- the time to truncate a file as the meta-data updates are ing needs for larger file systems to store personal digital reduced. The extent format supported by Ext4 is shown media, desktop users will very soon want to remove the in Fig 1 and Fig 2. A full description of Ext4 features limit for Ext3 file system. Thus, the first change made can be found in [2]. in the Ext4 file system is to lift the maximum file system size from 232 blocks(16 TB with 4 KB blocksize) to 248 Most files need only a few extents to describe their blocks. logical-to-physical block mapping, which can be ac- commodated within the inode or a single extent map Extent mapping is also used in Ext4 to represent new block. However, some extreme cases, such as sparse files, rather than the double, triple indirect block map- files with random allocation patterns, or a very badly ping used in Ext2/3. Extents are being used in many fragmented file system, are not efficiently represented • 263 • 264 • Ext4 block and inode allocator improvements leaf nodes strictions in Ext4’s block groups has made it possible ext4_inode disk blocks node header index node to rethink meta-data placement and inode allocation in extent ways not possible in Ext3. node header i_block . extent index This paper is organized into the following sections. In eh_header extent Section 2.1 and 2.2, we give some background on Ext3 root . block allocation principles and current limitations. In . Section 2.3, we give a detailed description of the new node header extent index multiple block allocator and how it addresses the limita- extent tions facing the Ext3 file system. Section 2.4 compares . the Ext3 and Ext4 block allocators with some perfor- mance data we collected. extent Finally, we discuss the inode allocator changes made in Ext4. We start with Section 4.1, describing the Ext3 inode allocation policy, the impact that the inode allo- Figure 2: Ext4 extent tree layout cation has on overall file system performance, and how changing the concept of a block group can lead to per- using extent maps. In Ext4, it is more important to have formance improvements. In Section 4.3, we explore a an advanced block allocator to reduce file fragmenta- new inode allocator that uses this new concept in meta- tion. A well-designed block allocator should pack small data allocation to manipulate block allocation and data files close to each other for locality and also place large locality on disk. Later, we examine the performance im- files contiguously on disk to improve I/O performance. provements in the Ext4 file system due to the changing of block group concept and the new inode allocator. Fi- The block allocator in the Ext3 file system does limited nally, we will discuss some potential future work in Sec- work to reduce file fragmentation and maintains group tion 4.5. locality for small files under the same directory. The Ext3 allocator tries to allocate multiple blocks on a best 2 Ext4 Multiple Blocks Allocator effort basis but does not do a smart search to find a bet- ter location to place a large file. It is also unaware of In this section we give some background on the Ext2/3 the relationship between different files, thus it is quite block allocation before we discuss the new Ext4 block possible to place small related files far apart, causing allocator. We refer to the old block allocator as the Ext3 extra seeks when loading a large number of related files. block allocator and the new multiple block allocator as Ext4 block allocation tries to address these two prob- the Ext4 block allocator for simplicity. lems with the new multiple block allocator while still making it possible to use the old block allocator. Mul- tiple block allocation can be enabled or disabled by 2.1 Ext3 block allocator mount option -o mballoc and -o nomballoc, re- spectively. The current development version of Ext4 file Block allocation is the heart of a file system design. system enables the multiple block allocator by default. Overall, the goal of file system block allocation is to reduce disk seek time by reducing file system fragmen- While a lot of work has gone into the block allocator, tation and maintaining locality for related files. Also, one must not forget that the inode allocator is what de- it needs to scale well on large file systems and paral- termines where blocks start getting allocated to begin lel allocation scenarios. Here is a short summary of the with. While disk platter density has increased dramat- strategy used in the Ext3 block allocator: ically over the years, the old Ext3 inode allocator does little to ensure data and meta-data locality in order to To scale well, the Ext3 file system is partitioned into 128 take advantage of that density and avoid large seeks. MB block group chunks. Each block group maintains a Ext4 has begun exploring the possibilities of compact- single block bitmap to describe data block availability ing data to increase locality and reduce seeks, which ul- inside this block group. This way allocation on different timately leads to better performance. Removal of re- block groups can be done in parallel. 2008 Linux Symposium, Volume One • 265 When allocating a block for a file, the Ext3 block alloca- Ext3 block allocation for small files tor always starts from the block group where the inode 10000 "ext3-small-files" structure is stored to keep the meta-data and data blocks close to each other. When there are no free blocks avail- 5000 able in the target block group it will search for a free block from the rest of the block groups. Ext3 always tries to keep the files under the same directory close to 0 each other until the parent block group is filled. To reduce large file fragmentation Ext3 uses a goal block -5000 to hint where it should allocate the next block from. If the application is doing a sequential I/O the target is to -10000 get the block following the last allocated block. When the target block is not available it will search further to find a free extent of at least 8 blocks and starts allocation -15000 from there. This way the resulting allocations will be Physical block number relative to first physical allocated contiguous. -20000 0 10 20 30 40 50 60 In case of multiple files allocating blocks concurrently, Logical block number the Ext3 block allocator uses block reservation to make Figure 3: Ext3 block allocator for small files sure that subsequent requests for blocks for a particular file get served before it is interleaved with other files. Reserving blocks which can be used to satisfy the subse- quent requests enable the block allocator to place blocks read during boot. If the files are placed far apart on corresponding to a file nearby. There is a per-file reser- the disk the bootup process would be delayed by ex- vation window, indicating the range of disk blocks re- pensive seeks across the underlying device to load all served for this file. However, the per-file reservation the files. If the block allocator could place these related window is done purely in memory. Each block alloca- small files closer it would be a great benefit to the read tion will first check the file’s own reservation window performance. before starts to find unreserved free block on bitmap.
Load more

Recommended publications
  • STAT 625: Statistical Case Studies 1 Our Computing Environment(S)
    John W. Emerson, Department of Statistics, Yale University © 2013 1 STAT 625: Statistical Case Studies John W. Emerson Yale University Abstract This term, I’ll generally present brief class notes and scripts, but much of the lecture material will simply be presented in class and/or available online. However, student participation is a large part of this course, and at any time I may call upon any of you to share some of your work. Be prepared. This won’t be a class where you sit and absorb material. I strongly encourage you to work with other students; you can learn a lot from each other. To get anything out of this course you’ll need to put in the time for the sake of learning and strengthening your skills, not for the sake of jumping through the proverbial hoop. Lesson 1: Learning how to communicate. This document was created using LATEX and Sweave (which is really an R package). There are some huge advantages to a workflow like this, relating to a topic called reproducible research. Here’s my thought: pay your dues now, reap the benefits later. Don’t trust me on everything, but trust me on this. A sister document was created using R Markdown and the markdown package, and this is also acceptable. Microsoft Office is not. So, in today’s class I’ll show you how I produced these documents and I’ll give you the required files. I recommend you figure out how to use LATEX on your own computer. You already have Sweave, because it comes with R.
    [Show full text]
  • System Calls and I/O
    System Calls and I/O CS 241 January 27, 2012 Copyright ©: University of Illinois CS 241 Staff 1 This lecture Goals Get you familiar with necessary basic system & I/O calls to do programming Things covered in this lecture Basic file system calls I/O calls Signals Note: we will come back later to discuss the above things at the concept level Copyright ©: University of Illinois CS 241 Staff 2 System Calls versus Function Calls? Copyright ©: University of Illinois CS 241 Staff 3 System Calls versus Function Calls Function Call Process fnCall() Caller and callee are in the same Process - Same user - Same “domain of trust” Copyright ©: University of Illinois CS 241 Staff 4 System Calls versus Function Calls Function Call System Call Process Process fnCall() sysCall() OS Caller and callee are in the same Process - Same user - OS is trusted; user is not. - Same “domain of trust” - OS has super-privileges; user does not - Must take measures to prevent abuse Copyright ©: University of Illinois CS 241 Staff 5 System Calls System Calls A request to the operating system to perform some activity System calls are expensive The system needs to perform many things before executing a system call The computer (hardware) saves its state The OS code takes control of the CPU, privileges are updated. The OS examines the call parameters The OS performs the requested function The OS saves its state (and call results) The OS returns control of the CPU to the caller Copyright ©: University of Illinois CS 241 Staff 6 Steps for Making a System Call
    [Show full text]
  • CS 5600 Computer Systems
    CS 5600 Computer Systems Lecture 10: File Systems What are We Doing Today? • Last week we talked extensively about hard drives and SSDs – How they work – Performance characterisEcs • This week is all about managing storage – Disks/SSDs offer a blank slate of empty blocks – How do we store files on these devices, and keep track of them? – How do we maintain high performance? – How do we maintain consistency in the face of random crashes? 2 • ParEEons and MounEng • Basics (FAT) • inodes and Blocks (ext) • Block Groups (ext2) • Journaling (ext3) • Extents and B-Trees (ext4) • Log-based File Systems 3 Building the Root File System • One of the first tasks of an OS during bootup is to build the root file system 1. Locate all bootable media – Internal and external hard disks – SSDs – Floppy disks, CDs, DVDs, USB scks 2. Locate all the parEEons on each media – Read MBR(s), extended parEEon tables, etc. 3. Mount one or more parEEons – Makes the file system(s) available for access 4 The Master Boot Record Address Size Descripon Hex Dec. (Bytes) Includes the starEng 0x000 0 Bootstrap code area 446 LBA and length of 0x1BE 446 ParEEon Entry #1 16 the parEEon 0x1CE 462 ParEEon Entry #2 16 0x1DE 478 ParEEon Entry #3 16 0x1EE 494 ParEEon Entry #4 16 0x1FE 510 Magic Number 2 Total: 512 ParEEon 1 ParEEon 2 ParEEon 3 ParEEon 4 MBR (ext3) (swap) (NTFS) (FAT32) Disk 1 ParEEon 1 MBR (NTFS) 5 Disk 2 Extended ParEEons • In some cases, you may want >4 parEEons • Modern OSes support extended parEEons Logical Logical ParEEon 1 ParEEon 2 Ext.
    [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]
  • Comparing Filesystem Performance: Red Hat Enterprise Linux 6 Vs
    COMPARING FILE SYSTEM I/O PERFORMANCE: RED HAT ENTERPRISE LINUX 6 VS. MICROSOFT WINDOWS SERVER 2012 When choosing an operating system platform for your servers, you should know what I/O performance to expect from the operating system and file systems you select. In the Principled Technologies labs, using the IOzone file system benchmark, we compared the I/O performance of two operating systems and file system pairs, Red Hat Enterprise Linux 6 with ext4 and XFS file systems, and Microsoft Windows Server 2012 with NTFS and ReFS file systems. Our testing compared out-of-the-box configurations for each operating system, as well as tuned configurations optimized for better performance, to demonstrate how a few simple adjustments can elevate I/O performance of a file system. We found that file systems available with Red Hat Enterprise Linux 6 delivered better I/O performance than those shipped with Windows Server 2012, in both out-of- the-box and optimized configurations. With I/O performance playing such a critical role in most business applications, selecting the right file system and operating system combination is critical to help you achieve your hardware’s maximum potential. APRIL 2013 A PRINCIPLED TECHNOLOGIES TEST REPORT Commissioned by Red Hat, Inc. About file system and platform configurations While you can use IOzone to gauge disk performance, we concentrated on the file system performance of two operating systems (OSs): Red Hat Enterprise Linux 6, where we examined the ext4 and XFS file systems, and Microsoft Windows Server 2012 Datacenter Edition, where we examined NTFS and ReFS file systems.
    [Show full text]
  • Silicon Graphics, Inc. Scalable Filesystems XFS & CXFS
    Silicon Graphics, Inc. Scalable Filesystems XFS & CXFS Presented by: Yingping Lu January 31, 2007 Outline • XFS Overview •XFS Architecture • XFS Fundamental Data Structure – Extent list –B+Tree – Inode • XFS Filesystem On-Disk Layout • XFS Directory Structure • CXFS: shared file system ||January 31, 2007 Page 2 XFS: A World-Class File System –Scalable • Full 64 bit support • Dynamic allocation of metadata space • Scalable structures and algorithms –Fast • Fast metadata speeds • High bandwidths • High transaction rates –Reliable • Field proven • Log/Journal ||January 31, 2007 Page 3 Scalable –Full 64 bit support • Large Filesystem – 18,446,744,073,709,551,615 = 264-1 = 18 million TB (exabytes) • Large Files – 9,223,372,036,854,775,807 = 263-1 = 9 million TB (exabytes) – Dynamic allocation of metadata space • Inode size configurable, inode space allocated dynamically • Unlimited number of files (constrained by storage space) – Scalable structures and algorithms (B-Trees) • Performance is not an issue with large numbers of files and directories ||January 31, 2007 Page 4 Fast –Fast metadata speeds • B-Trees everywhere (Nearly all lists of metadata information) – Directory contents – Metadata free lists – Extent lists within file – High bandwidths (Storage: RM6700) • 7.32 GB/s on one filesystem (32p Origin2000, 897 FC disks) • >4 GB/s in one file (same Origin, 704 FC disks) • Large extents (4 KB to 4 GB) • Request parallelism (multiple AGs) • Delayed allocation, Read ahead/Write behind – High transaction rates: 92,423 IOPS (Storage: TP9700)
    [Show full text]
  • Lab #6: Stat Overview Stat
    February 17, 2017 CSC 357 1 Lab #6: Stat Overview The purpose of this lab is for you to retrieve from the filesystem information pertaining to specified files. You will use portions of this lab in Assignment #4, so be sure to write code that can be reused. stat Write a simplified version of the stat utility available on some Unix distributions. This program should take any number of file names as command-line arguments and output information pertaining to each file as described below (you should use the stat system call). The output from your program should look as follows: File: ‘Makefile’ Type: Regular File Size: 214 Inode: 4702722 Links: 1 Access: -rw------- The stat system call provides more information about a file, but this lab only requires the above. The format of each field follows: • File: the name of the file being examined. • Type: the type of file output as “Regular File”, “Directory”, “Character Device”, “Block Device”, “FIFO”, or “Symbolic Link” • Size: the number of bytes in the file. • Inode: the file’s inode. • Links: the number of links to the file. • Access: the access permissions for the file. This field is the most involved since the output string can take many forms. The first bit of the access permissions denotes the type (similar to the second field above). The valid characters for the first bit are: b – Block special file. c – Character special file. d – Directory. l – Symbolic link. p – FIFO. - – Regular file. The remaining bits denote the read, write and execute permissions for the user, group, and others.
    [Show full text]
  • How UNIX Organizes and Accesses Files on Disk Why File Systems
    UNIX File Systems How UNIX Organizes and Accesses Files on Disk Why File Systems • File system is a service which supports an abstract representation of the secondary storage to the OS • A file system organizes data logically for random access by the OS. • A virtual file system provides the interface between the data representation by the kernel to the user process and the data presentation to the kernel in memory. The file and directory system cache. • Because of the performance disparity between disk and CPU/memory, file system performance is the paramount issue for any OS Main memory vs. Secondary storage • Small (MB/GB) Large (GB/TB) • Expensive Cheap -2 -3 • Fast (10-6/10-7 sec) Slow (10 /10 sec) • Volatile Persistent Cannot be directly accessed • Directly accessible by CPU by CPU – Interface: (virtual) memory – Data should be first address brought into the main memory Secondary storage (disk) • A number of disks directly attached to the computer • Network attached disks accessible through a fast network - Storage Area Network (SAN) • Simple disks (IDE, SATA) have a described disk geometry. Sector size is the minimum read/write unit of data (usually 512Bytes) – Access: (#surface, #track, #sector) • Smart disks (SCSI, SAN, NAS) hide the internal disk layout using a controller type function – Access: (#sector) • Moving arm assembly (Seek) is expensive – Sequential access is x100 times faster than the random access Internal disk structure • Disk structure User Process Accessing Data • Given the file name. Get to the file’s FCB using the file system catalog (Open, Close, Set_Attribute) • The catalog maps a file name to the FCB – Checks permissions • file_handle=open(file_name): – search the catalog and bring FCB into the memory – UNIX: in-memory FCB: in-core i-node • Use the FCB to get to the desired offset within the file data: (CREATE, DELETE, SEEK, TRUNCATE) • close(file_handle): release FCB from memory Catalog Organization (Directories) • In UNIX, special files (not special device files) called directories contain information about other files.
    [Show full text]
  • NOVA: a Log-Structured File System for Hybrid Volatile/Non
    NOVA: A Log-structured File System for Hybrid Volatile/Non-volatile Main Memories Jian Xu and Steven Swanson, University of California, San Diego https://www.usenix.org/conference/fast16/technical-sessions/presentation/xu This paper is included in the Proceedings of the 14th USENIX Conference on File and Storage Technologies (FAST ’16). February 22–25, 2016 • Santa Clara, CA, USA ISBN 978-1-931971-28-7 Open access to the Proceedings of the 14th USENIX Conference on File and Storage Technologies is sponsored by USENIX NOVA: A Log-structured File System for Hybrid Volatile/Non-volatile Main Memories Jian Xu Steven Swanson University of California, San Diego Abstract Hybrid DRAM/NVMM storage systems present a host of opportunities and challenges for system designers. These sys- Fast non-volatile memories (NVMs) will soon appear on tems need to minimize software overhead if they are to fully the processor memory bus alongside DRAM. The result- exploit NVMM’s high performance and efficiently support ing hybrid memory systems will provide software with sub- more flexible access patterns, and at the same time they must microsecond, high-bandwidth access to persistent data, but provide the strong consistency guarantees that applications managing, accessing, and maintaining consistency for data require and respect the limitations of emerging memories stored in NVM raises a host of challenges. Existing file sys- (e.g., limited program cycles). tems built for spinning or solid-state disks introduce software Conventional file systems are not suitable for hybrid mem- overheads that would obscure the performance that NVMs ory systems because they are built for the performance char- should provide, but proposed file systems for NVMs either in- acteristics of disks (spinning or solid state) and rely on disks’ cur similar overheads or fail to provide the strong consistency consistency guarantees (e.g., that sector updates are atomic) guarantees that applications require.
    [Show full text]
  • Oracle® Linux 7 Managing File Systems
    Oracle® Linux 7 Managing File Systems F32760-07 August 2021 Oracle Legal Notices Copyright © 2020, 2021, Oracle and/or its affiliates. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract.
    [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]
  • File Systems
    File Systems Profs. Bracy and Van Renesse based on slides by Prof. Sirer Storing Information • Applications could store information in the process address space • Why is this a bad idea? – Size is limited to size of virtual address space – The data is lost when the application terminates • Even when computer doesn’t crash! – Multiple process might want to access the same data File Systems • 3 criteria for long-term information storage: 1. Able to store very large amount of information 2. Information must survive the processes using it 3. Provide concurrent access to multiple processes • Solution: – Store information on disks in units called files – Files are persistent, only owner can delete it – Files are managed by the OS File Systems: How the OS manages files! File Naming • Motivation: Files abstract information stored on disk – You do not need to remember block, sector, … – We have human readable names • How does it work? – Process creates a file, and gives it a name • Other processes can access the file by that name – Naming conventions are OS dependent • Usually names as long as 255 characters is allowed • Windows names not case sensitive, UNIX family is File Extensions • Name divided into 2 parts: Name+Extension • On UNIX, extensions are not enforced by OS – Some applications might insist upon them • Think: .c, .h, .o, .s, etc. for C compiler • Windows attaches meaning to extensions – Tries to associate applications to file extensions File Access • Sequential access – read all bytes/records from the beginning – particularly convenient for magnetic tape • Random access – bytes/records read in any order – essential for database systems File Attributes • File-specific info maintained by the OS – File size, modification date, creation time, etc.
    [Show full text]