DOCSLIB.ORG

Chapter 11: File-System Interface

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Chapter 11: File-System Interface Chapter 11: File-System Interface Chapter Outline I File Concept I Access Methods I Directory Structure I File System Mounting I File Sharing I Protection Operating System Concepts 11.1 Silberschatz, Galvin and Gagne 2002 File Systems I File System consists of ✦ A collection of files ✦ A directory structure ✦ (possibly) partitions I Important Issues ✦ File protection ✦ The semantics of file sharing I Note: Historically, operating systems and file systems have been viewed as distinct entities. I From the perspective of the modern user, this distinction is often blurred. Operating System Concepts 11.2 Silberschatz, Galvin and Gagne 2002 File Concept I The operating system provides a uniform logical abstraction for the physical storage of information. I Storage devices are nonvolatile. I A file is a named collection of related information that is recorded on secondary storage. I Contiguous logical address space I Types: ✦ Data ✔ numeric ✔ character ✔ binary ✦ Program ✔ Source, object and executable file formats Operating System Concepts 11.3 Silberschatz, Galvin and Gagne 2002 File Attributes I Name – only information kept in human-readable form. I Identifier – a unique tag (i.e., an internal number) that identifies the file within the file system. I Type – needed for systems that support different types. I Location – a pointer to file location on device. I Size – current file size. I Protection – controls who can do reading, writing, executing. I Time, date, and user identification – data for protection, security, and usage monitoring. I Information about files are kept in the directory structure, which is maintained on the disk. Operating System Concepts 11.4 Silberschatz, Galvin and Gagne 2002 File Operations I Create I Write I Read I Reposition within file – file seek I Delete I Truncate I Open(Fi) – search the directory structure on disk for entry Fi, and move the content of entry to memory. I Close (Fi) – move the content of entry Fi in memory to directory structure on disk. Operating System Concepts 11.5 Silberschatz, Galvin and Gagne 2002 Claypool Example: Unix open() int open(char *path, int flags [, int mode]) I path is name of file I flags is bitmap to set switch ✦ O_RDONLY, O_WRONLY… ✦ O_CREATE then use mode for perms I On success, returns index Operating System Concepts 11.6 Silberschatz, Galvin and Gagne 2002 Claypool Example: Unix open() Under the Hood int fid = open(“blah”, flags); read(fid, …); User Space System Space 0 stdin 1 stdou 2 stdert ... r 3 File File Structure ... Descriptor ... (where blocks are) (index) (attributes) (Per process) (Per device) Operating System Concepts 11.7 Silberschatz, Galvin and Gagne 2002 Claypool Example: WinNT/2000 CreateFile() I Returns file object handle: HANDLE CreateFile ( lpFileName, // name of file dwDesiredAccess, // read-write dwShareMode, // shared or not lpSecurity, // permissions ... ) I File objects used for all: files, directories, disk drives, ports, pipes, sockets and console Operating System Concepts 11.8 Silberschatz, Galvin and Gagne 2002 File Types – Name, Extension Operating System Concepts 11.9 Silberschatz, Galvin and Gagne 2002 File Structure I File types may be used to indicate the internal structure of a file. I An OS may require a file to have a specific structure so that the OS will provide special operations for those files conforming to the set of system-supported file structures. ✦ e.g., VMS supported three defined file structures. ✦ Others (UNIX, MS-DOS) support a minimal number of file structures. I This is an obvious tradeoff between flexibility and system support! Operating System Concepts 11.10 Silberschatz, Galvin and Gagne 2002 Access Methods I Access methods determine the way that files are accessed and read into memory. I Some systems only support one access method while other OS’s support many access methods. I Sequential Access ✦ The most common method used by editors and compilers. ✦ Information is processed in order. read next write next reset no read after last write (rewrite) Operating System Concepts 11.11 Silberschatz, Galvin and Gagne 2002 Sequential Access File I Based on a tape model of a file. I May be able to skip forward nnrecords. Operating System Concepts 11.12 Silberschatz, Galvin and Gagne 2002 Direct Access File I File is made up of fixed-length logical records that allow programs to read and write records in no particular order. I The files is viewed as a numbered sequence of blocks or records. I Very useful in databases. I Direct Access {n = relative block number} read n write n position to n read next write next rewrite n Operating System Concepts 11.13 Silberschatz, Galvin and Gagne 2002 Simulation of Sequential Access on a Direct-access File Operating System Concepts 11.14 Silberschatz, Galvin and Gagne 2002 Example of Index and Relative Files I Index Sequential Access Method (ISAM) – uses indexes in a hierarchy to point to records in a file. Operating System Concepts 11.15 Silberschatz, Galvin and Gagne 2002 Directory Structure I Partitions (or Volumes) – can be viewed as the abstraction of virtual disks. I Disks can be partitioned into separate areas such that each partition is treated as a separate storage device. I The other way -- a partition may be defined to be more than one disk device. I Partitions can store multiple operating systems such that a system can boot more than one OS. I Each partition contains information about files in a device directory (or a VTOC – Volume Table of Contents). I Each directory records file attribute information. Operating System Concepts 11.16 Silberschatz, Galvin and Gagne 2002 Directory Structure I A collection of nodes containing information about all files. Directory Files F 2 F 4 F 1 F 3 F n Both the directory structure and the files reside on disk. Backups of these two structures are kept on tapes. Operating System Concepts 11.17 Silberschatz, Galvin and Gagne 2002 A Typical File System Organization I A directory can viewed as a “symbol table” that translates file names into their directory entries. Operating System Concepts 11.18 Silberschatz, Galvin and Gagne 2002 Information in a Device Directory I Name I Type I Address I Current length I Maximum length I Date last accessed (for archival) I Date last updated (for dump) I Owner ID (who pays) I Protection information (discuss later) Operating System Concepts 11.19 Silberschatz, Galvin and Gagne 2002 Directory Operations I Search for a file – need to find a particular entry or be able to find file names based on a pattern match. I Create a file - and add its entry to the directory. I Delete a file –and remove it from the directory. I List a directory – list both the files in the directory and the directory contents for each file. I Rename a file – renaming may imply changing the position of the file entry in the directory structure. I Traverse the file system – the directory needs a logical structure such that every directory and every file within each directory can be accessing efficiently. Operating System Concepts 11.20 Silberschatz, Galvin and Gagne 2002 Directory Design Goal To organize the logical structure to obtain: I Efficiency – locating a file quickly. I Naming – convenient to users. ✦ Two users can have same name for different files. ✦ The same file can have several different names. I Grouping – logical grouping of files by properties, (e.g., all Java programs, all games, …) Operating System Concepts 11.21 Silberschatz, Galvin and Gagne 2002 Single-Level Directory I The simplest solution:: A single-level directory with file entries for all users contained in the same directory. I Advantages: ✦ Easy to support and understand. I Disadvantages:: ✦ Requires unique file names {the naming problem}. ✦ No natural system for keeping track of file names {the grouping problem}. Operating System Concepts 11.22 Silberschatz, Galvin and Gagne 2002 Two-Level Directory I Standard solution: a separate directory for each user. I The system’s Master File Directory (MFD) has pointers to individual User File Directories ((UFD’sUFD’sUFD’s).). I File names default to localized UFD for all operations. Operating System Concepts 11.23 Silberschatz, Galvin and Gagne 2002 TwoTwo---LevelLevel Directory I Advantages ✦ Solves the name-collision problem. ✦ Isolates users from one another ! a form of protection. ✦ Efficient searching. I Disadvantages ✦ Restricts user cooperation. ✦ No logical grouping capability (other than by user). Operating System Concepts 11.24 Silberschatz, Galvin and Gagne 2002 Path Name I If a user can access another user’s files, the concept of path name is needed. I In two-level directory, this tree structure has MFD as root of path through UFD to user file name at leaf. I Path name :: username + filename I Standard syntax -- /user/file.ext Add Partitions I Additional syntax needed to specify partition ✦ e.g. in MS-DOS C:C:\\\useruseruser\\\file.extfile.ext System files I Dotted files in Unix Operating System Concepts 11.25 Silberschatz, Galvin and Gagne 2002 Path Name System File Issues I Those programs provided as part of the system (e.g. loaders, compilers, utility routines) I e.g., Dotted files in Unix I Another tradeoff issue ✦ Copy all system files into each UFD OR ✦ Create special user file directory that contains the system files. ✔ Note: This complicates the file search procedure. ✔ Default is to search local UFD, and then special UFD. I To override this default search scheme, the user specifies a specific sequence of directories to be searched when a files is named – the search path. Operating System Concepts 11.26 Silberschatz, Galvin and Gagne 2002 Tree-Structured Directories I This generalization to a directory tree structure of arbitrary height allows users to create their own subdirectories and organize their files accordingly. Directory I Becomes simply another file. I Contains a set of files or subdirectories.
Load more

Recommended publications
  • The Microsoft Compound Document File Format"
    OpenOffice.org's Documentation of the Microsoft Compound Document File Format Author Daniel Rentz ✉ mailto:[email protected] http://sc.openoffice.org License Public Documentation License Contributors Other sources Hyperlinks to Wikipedia ( http://www.wikipedia.org) for various extended information Mailing list ✉ mailto:[email protected] Subscription ✉ mailto:[email protected] Download PDF http://sc.openoffice.org/compdocfileformat.pdf XML http://sc.openoffice.org/compdocfileformat.odt Project started 2004-Aug-30 Last change 2007-Aug-07 Revision 1.5 Contents 1 Introduction ......................................................................................................... 3 1.1 License Notices 3 1.2 Abstract 3 1.3 Used Terms, Symbols, and Formatting 4 2 Storages and Streams ........................................................................................... 5 3 Sectors and Sector Chains ................................................................................... 6 3.1 Sectors and Sector Identifiers 6 3.2 Sector Chains and SecID Chains 7 4 Compound Document Header ............................................................................. 8 4.1 Compound Document Header Contents 8 4.2 Byte Order 9 4.3 Sector File Offsets 9 5 Sector Allocation ............................................................................................... 10 5.1 Master Sector Allocation Table 10 5.2 Sector Allocation Table 11 6 Short-Streams ...................................................................................................
    [Show full text]
  • Enhancing the Accuracy of Synthetic File System Benchmarks Salam Farhat Nova Southeastern University, [email protected]
    Nova Southeastern University NSUWorks CEC Theses and Dissertations College of Engineering and Computing 2017 Enhancing the Accuracy of Synthetic File System Benchmarks Salam Farhat Nova Southeastern University, [email protected] This document is a product of extensive research conducted at the Nova Southeastern University College of Engineering and Computing. For more information on research and degree programs at the NSU College of Engineering and Computing, please click here. Follow this and additional works at: https://nsuworks.nova.edu/gscis_etd Part of the Computer Sciences Commons Share Feedback About This Item NSUWorks Citation Salam Farhat. 2017. Enhancing the Accuracy of Synthetic File System Benchmarks. Doctoral dissertation. Nova Southeastern University. Retrieved from NSUWorks, College of Engineering and Computing. (1003) https://nsuworks.nova.edu/gscis_etd/1003. This Dissertation is brought to you by the College of Engineering and Computing at NSUWorks. It has been accepted for inclusion in CEC Theses and Dissertations by an authorized administrator of NSUWorks. For more information, please contact [email protected]. Enhancing the Accuracy of Synthetic File System Benchmarks by Salam Farhat A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor in Philosophy in Computer Science College of Engineering and Computing Nova Southeastern University 2017 We hereby certify that this dissertation, submitted by Salam Farhat, conforms to acceptable standards and is fully adequate in scope and quality to fulfill the dissertation requirements for the degree of Doctor of Philosophy. _____________________________________________ ________________ Gregory E. Simco, Ph.D. Date Chairperson of Dissertation Committee _____________________________________________ ________________ Sumitra Mukherjee, Ph.D. Date Dissertation Committee Member _____________________________________________ ________________ Francisco J.
    [Show full text]
  • File Formats
    man pages section 4: File Formats Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054 U.S.A. Part No: 817–3945–10 September 2004 Copyright 2004 Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, docs.sun.com, AnswerBook, AnswerBook2, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK and Sun™ Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements.
    [Show full text]
  • Mac OS X Server Administrator's Guide
    034-9285.S4AdminPDF 6/27/02 2:07 PM Page 1 Mac OS X Server Administrator’s Guide K Apple Computer, Inc. © 2002 Apple Computer, Inc. All rights reserved. Under the copyright laws, this publication may not be copied, in whole or in part, without the written consent of Apple. The Apple logo is a trademark of Apple Computer, Inc., registered in the U.S. and other countries. Use of the “keyboard” Apple logo (Option-Shift-K) for commercial purposes without the prior written consent of Apple may constitute trademark infringement and unfair competition in violation of federal and state laws. Apple, the Apple logo, AppleScript, AppleShare, AppleTalk, ColorSync, FireWire, Keychain, Mac, Macintosh, Power Macintosh, QuickTime, Sherlock, and WebObjects are trademarks of Apple Computer, Inc., registered in the U.S. and other countries. AirPort, Extensions Manager, Finder, iMac, and Power Mac are trademarks of Apple Computer, Inc. Adobe and PostScript are trademarks of Adobe Systems Incorporated. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Netscape Navigator is a trademark of Netscape Communications Corporation. RealAudio is a trademark of Progressive Networks, Inc. © 1995–2001 The Apache Group. All rights reserved. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd. 062-9285/7-26-02 LL9285.Book Page 3 Tuesday, June 25, 2002 3:59 PM Contents Preface How to Use This Guide 39 What’s Included
    [Show full text]
  • [13주차] Sysfs and Procfs
    1 7 Computer Core Practice1: Operating System Week13. sysfs and procfs Jhuyeong Jhin and Injung Hwang Embedded Software Lab. Embedded Software Lab. 2 sysfs 7 • A pseudo file system provided by the Linux kernel. • sysfs exports information about various kernel subsystems, HW devices, and associated device drivers to user space through virtual files. • The mount point of sysfs is usually /sys. • sysfs abstrains devices or kernel subsystems as a kobject. Embedded Software Lab. 3 How to create a file in /sys 7 1. Create and add kobject to the sysfs 2. Declare a variable and struct kobj_attribute – When you declare the kobj_attribute, you should implement the functions “show” and “store” for reading and writing from/to the variable. – One variable is one attribute 3. Create a directory in the sysfs – The directory have attributes as files • When the creation of the directory is completed, the directory and files(attributes) appear in /sys. • Reference: ${KERNEL_SRC_DIR}/include/linux/sysfs.h ${KERNEL_SRC_DIR}/fs/sysfs/* • Example : ${KERNEL_SRC_DIR}/kernel/ksysfs.c Embedded Software Lab. 4 procfs 7 • A special filesystem in Unix-like operating systems. • procfs presents information about processes and other system information in a hierarchical file-like structure. • Typically, it is mapped to a mount point named /proc at boot time. • procfs acts as an interface to internal data structures in the kernel. The process IDs of all processes in the system • Kernel provides a set of functions which are designed to make the operations for the file in /proc : “seq_file interface”. – We will create a file in procfs and print some data from data structure by using this interface.
    [Show full text]
  • Filesystem Hierarchy Standard
    Filesystem Hierarchy Standard LSB Workgroup, The Linux Foundation Filesystem Hierarchy Standard LSB Workgroup, The Linux Foundation Version 3.0 Publication date March 19, 2015 Copyright © 2015 The Linux Foundation Copyright © 1994-2004 Daniel Quinlan Copyright © 2001-2004 Paul 'Rusty' Russell Copyright © 2003-2004 Christopher Yeoh Abstract This standard consists of a set of requirements and guidelines for file and directory placement under UNIX-like operating systems. The guidelines are intended to support interoperability of applications, system administration tools, development tools, and scripts as well as greater uniformity of documentation for these systems. All trademarks and copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Permission is granted to make and distribute verbatim copies of this standard provided the copyright and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this standard under the conditions for verbatim copying, provided also that the title page is labeled as modified including a reference to the original standard, provided that information on retrieving the original standard is included, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this standard into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the copyright holder. Dedication This release is dedicated to the memory of Christopher Yeoh, a long-time friend and colleague, and one of the original editors of the FHS.
    [Show full text]
  • Refs: Is It a Game Changer? Presented By: Rick Vanover, Director, Technical Product Marketing & Evangelism, Veeam
    Technical Brief ReFS: Is It a Game Changer? Presented by: Rick Vanover, Director, Technical Product Marketing & Evangelism, Veeam Sponsored by ReFS: Is It a Game Changer? OVERVIEW Backing up data is more important than ever, as data centers store larger volumes of information and organizations face various threats such as ransomware and other digital risks. Microsoft’s Resilient File System or ReFS offers a more robust solution than the old NT File System. In fact, Microsoft has stated that ReFS is the preferred data volume for Windows Server 2016. ReFS is an ideal solution for backup storage. By utilizing the ReFS BlockClone API, Veeam has developed Fast Clone, a fast, efficient storage backup solution. This solution offers organizations peace of mind through a more advanced approach to synthetic full backups. CONTEXT Rick Vanover discussed Microsoft’s Resilient File System (ReFS) and described how Veeam leverages this technology for its Fast Clone backup functionality. KEY TAKEAWAYS Resilient File System is a Microsoft storage technology that can transform the data center. Resilient File System or ReFS is a valuable Microsoft storage technology for data centers. Some of the key differences between ReFS and the NT File System (NTFS) are: ReFS provides many of the same limits as NTFS, but supports a larger maximum volume size. ReFS and NTFS support the same maximum file name length, maximum path name length, and maximum file size. However, ReFS can handle a maximum volume size of 4.7 zettabytes, compared to NTFS which can only support 256 terabytes. The most common functions are available on both ReFS and NTFS.
    [Show full text]
  • What Is UNIX? the Directory Structure Basic Commands Find
    What is UNIX? UNIX is an operating system like Windows on our computers. By operating system, we mean the suite of programs which make the computer work. It is a stable, multi-user, multi-tasking system for servers, desktops and laptops. The Directory Structure All the files are grouped together in the directory structure. The file-system is arranged in a hierarchical structure, like an inverted tree. The top of the hierarchy is traditionally called root (written as a slash / ) Basic commands When you first login, your current working directory is your home directory. In UNIX (.) means the current directory and (..) means the parent of the current directory. find command The find command is used to locate files on a Unix or Linux system. find will search any set of directories you specify for files that match the supplied search criteria. The syntax looks like this: find where-to-look criteria what-to-do All arguments to find are optional, and there are defaults for all parts. where-to-look defaults to . (that is, the current working directory), criteria defaults to none (that is, select all files), and what-to-do (known as the find action) defaults to ‑print (that is, display the names of found files to standard output). Examples: find . –name *.txt (finds all the files ending with txt in current directory and subdirectories) find . -mtime 1 (find all the files modified exact 1 day) find . -mtime -1 (find all the files modified less than 1 day) find . -mtime +1 (find all the files modified more than 1 day) find .
    [Show full text]
  • Lecture 17: Files and Directories
    11/1/16 CS 422/522 Design & Implementation of Operating Systems Lecture 17: Files and Directories Zhong Shao Dept. of Computer Science Yale University Acknowledgement: some slides are taken from previous versions of the CS422/522 lectures taught by Prof. Bryan Ford and Dr. David Wolinsky, and also from the official set of slides accompanying the OSPP textbook by Anderson and Dahlin. The big picture ◆ Lectures before the fall break: – Management of CPU & concurrency – Management of main memory & virtual memory ◆ Current topics --- “Management of I/O devices” – Last week: I/O devices & device drivers – Last week: storage devices – This week: file systems * File system structure * Naming and directories * Efficiency and performance * Reliability and protection 1 11/1/16 This lecture ◆ Implementing file system abstraction Physical Reality File System Abstraction block oriented byte oriented physical sector #’s named files no protection users protected from each other data might be corrupted robust to machine failures if machine crashes File system components ◆ Disk management User – Arrange collection of disk blocks into files File File ◆ Naming Naming access – User gives file name, not track or sector number, to locate data Disk management ◆ Security / protection – Keep information secure Disk drivers ◆ Reliability/durability – When system crashes, lose stuff in memory, but want files to be durable 2 11/1/16 User vs. system view of a file ◆ User’s view – Durable data structures ◆ System’s view (system call interface) – Collection of bytes (Unix) ◆ System’s view (inside OS): – Collection of blocks – A block is a logical transfer unit, while a sector is the physical transfer unit.
    [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]
  • File Management Virtual File System: Interface, Data Structures
    File management Virtual file system: interface, data structures Table of contents • Virtual File System (VFS) • File system interface Motto – Creating and opening a file – Reading from a file Everything is a file – Writing to a file – Closing a file • VFS data structures – Process data structures with file information – Structure fs_struct – Structure files_struct – Structure file – Inode – Superblock • Pipe vs FIFO 2 Virtual File System (VFS) VFS (source: Tizen Wiki) 3 Virtual File System (VFS) Linux can support many different (formats of) file systems. (How many?) The virtual file system uses a unified interface when accessing data in various formats, so that from the user level adding support for the new data format is relatively simple. This concept allows implementing support for data formats – saved on physical media (Ext2, Ext3, Ext4 from Linux, VFAT, NTFS from Microsoft), – available via network (like NFS), – dynamically created at the user's request (like /proc). This unified interface is fully compatible with the Unix-specific file model, making it easier to implement native Linux file systems. 4 File System Interface In Linux, processes refer to files using a well-defined set of system functions: – functions that support existing files: open(), read(), write(), lseek() and close(), – functions for creating new files: creat(), – functions used when implementing pipes: pipe() i dup(). The first step that the process must take to access the data of an existing file is to call the open() function. If successful, it passes the file descriptor to the process, which it can use to perform other operations on the file, such as reading (read()) and writing (write()).
    [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]