DOCSLIB.ORG

File System Implementation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
File System Implementation File System Implementation CISC3595, Spring 2015 1 Objectives for a File Management System ! Meet the data management needs of the user! ! Provide I/O support for a variety of storage device types! ! Provide a standardized set of I/O interface routines to user processes! ! Provide I/O support for multiple users (if needed)! ! Guarantee that the data in the file are valid! ! Minimize lost or destroyed data! ! Optimize performance Requirements for a general purpose system 1. user should be able to create, delete, read, write and modify files! 2. user may have controlled access to other users’ files! 3. user may control what type of accesses are allowed to his/her files! 4. user should be able to restructure his/her files! 5. user should be able to move data between files! 6. user should be able to back up and recover files in case of damage! 7. user should be able to access files using symbolic names Virtual File Systems ! Virtual File Systems (VFS):! ! same system call interface (API) used for different types of concrete file systems! ! Support numerous file system types! ! ext2, ufs, fat, vfat, hpfs, minix, isofs, sysv, hfs, affs, NTFS! ! /proc file system! ! NFS, CoDA, AFS ncpfs! ! umsdos, userfs 8 Virtual File Systems (1) Figure 4-18. Position of the virtual file system. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 Mount ! Various file systems are mounted at different directories (mounting points) in the files system name space! $ mount! $ /dev/sda3 on / type ext3 (rw,relatime,errors=remount-ro)! tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) ! proc on /proc type proc (rw,noexec,nosuid,nodev) ! sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) ! varrun on /var/run type tmpfs (rw,nosuid,mode=0755) ! varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777) udev on /dev type tmpfs (rw,mode=0755) ! tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) ! devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) fusectl on /sys/ fs/fuse/connections type fusectl (rw) lrm on /lib/modules/2.6.28-11-generic/volatile type tmpfs (rw,mode=755) securityfs on /sys/kernel/security type securityfs (rw) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) gvfs-fuse-daemon on /home/zhang/.gvfs type fuse.gvfs- fuse-daemon (rw,nosuid,nodev,user=zhang) 9 Hard Disk Accessing Hard disk ! ! Seek time: in ms! (moving read head to track)! Rotation time: in ms! (wait until sector rotate to read! head)! Transmission time: in hundreds of! MB/s! # of bytes/ (transfer speed) ! ! ! vs accessing RAM: ! 10 ns every 32 bits! Block • File system block: the allocation unit of disk storage space ! • Also transfer unit when read/write disk! • similar concept in paging memory management: page! • Always two’s power: 512, 1024, 2048, 4096, …! • Choosing block size: ! • Small block size => ? ! • Large block size => ? ! • In this class (chapter of book), assume an abstract view of disk: ! • a disk is nothing but an “array” of blocks, ! • We can read block k, write block k! • We want to support file system service we learnt last week! • hierarchy structure! • file/directory operations (system calls)… ! Disk Space Management Block Size (1) Figure 4-20. Percentage of files smaller than a given size (in bytes). Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 Disk Space Management Block Size (2) For more info,! See book P263! ! Data rate = ! ! Figure 4-21. The solid curve (left-hand scale) gives the data rate of a disk. The dashed curve (right-hand scale) gives the disk space efficiency. All files are 4 KB. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 File System Layout Boot block: used to boot operating system (i.e., load OS code into RAM)! Superblock: keep file system parameters ! Free space mgmt: what blocks in this partition is free ! i-nodes: metadata and address of blocks allocated to each file/directory! Figure 4-9. A possible file system layout. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 Outline ! Abstract view of hard disk! ! Disk space allocation and management! ! Efficiency and Performance! ! Recovery! ! NFS 20 Allocation Methods ! Allocate disk space to files! ! ! Contiguous allocation! ! ! Linked allocation! ! ! Indexed allocation 21 Contiguous Allocation ! Each file occupies a set of contiguous blocks on the disk! ! Pros:! ! Simple – only starting location (block #) and length (number of blocks) are required! ! Random access! ! Cons:! ! Wasteful of space: dynamic storage- allocation problem: how to satisfy request from list of non-contiguous free holes! ! External fragmentation! ! Files cannot grow 22 Linked Allocation ! Each file is a linked list of disk blocks: blocks may be scattered anywhere on the disk.! ! Directory contains pointer to the first and last blocks of the file.! ! pointer to next block is stored in block! ! data stored in each block is no more two’s power 23 Linked List Allocation Figure 4-11. Storing a file as a linked list of disk blocks. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 File-Allocation Table ! File-allocation table (FAT)! ! collectively store “next block” for entire file system in one table! ! used in MS-DOS and OS/2 (FAT12, FAT16,FAT32)! ! one FAT per partition! ! one entry for each disk block! ! store pointer to next block in file/directory! ! For each file, only needs to block # for the first block! 24 Linked List Allocation Using a Table in Memory Figure 4-12. Linked list allocation using a file allocation table in main memory. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 MS-DOS File System # of bits per entry Maximum partition size for different block sizes. The empty boxes represent forbidden combinations. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 Indexed Allocation (i-node, index-node) ! Brings all pointers (block #s) belonging to a file/ directory together into index block.! ! Each file has its own index block, or i-node (used in Unix file systems) 25 Indexed Allocation entry for a file 26 Combined Scheme: UNIX inode (4K bytes per block) 28 Free-Space Management (Cont.) ! Linked list (free list)! ! Cannot get contiguous space easily! ! No waste of space! ! Grouping ! ! First free block contains address of n free blocks! ! The n-th block therein contains address of another n free blocks, … ! ! Counting! ! Free blocks might be contiguous! ! Keep starting block # and length 30 Implementing Directories (1) A UNIX V7 directory entry. Figure 4-14. (a) A simple directory containing fixed-size entries with the disk addresses and attributes in the directory entry. (b) A directory in which each entry just refers to an i-node. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 Shared Files (1) Figure 4-16. File system containing a shared file. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 Shared Files (2) Figure 4-17. (a) Situation prior to linking. (b) After the link is created. (c) After the original owner removes the file. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 Outline ! Abstract view of hard disk! ! Disk space allocation and management! ! Efficiency and Performance! ! Recovery! ! NFS 20 Caching (1) Figure 4-28. The buffer cache data structures. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 Caching (2) • Some blocks, such as i-node blocks, are rarely referenced two times within a short interval. ! • Consider a modified LRU scheme, taking two factors into account: •Is the block likely to be needed again soon? •Is the block essential to the consistency of the file system? Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 Outline ! Abstract view of hard disk! ! Disk space allocation and management! ! Efficiency and Performance! ! Recovery! ! NFS 20 The MS-DOS File System (1) Figure 4-31. The MS-DOS directory entry. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 The UNIX V7 File System (1) Figure 4-33. A UNIX V7 directory entry. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 The UNIX V7 File System (2) Figure 4-34. A UNIX i-node. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 The UNIX V7 File System (3) Figure 4-35. The steps in looking up /usr/ast/mbox. Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved. 0-13-6006639 File system structures in memory ! Mount table: contains info. about each mounted volume! ! In-memory directory-structure cache: contains recent accessed directory info.! ! For a directory that is a mounting point, contains flag indicating it’s a mount point, and a pointer to an entry in mount table! ! System-wide open-file table: a copy of i-node for each open file! ! Per-process open-file table: contains pointer to appropriate entry in system-wide open-file table! ! Buffer: hold file system blocks being read from disk or written to disk 12 Supporting file system interface:
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]
  • 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]
  • 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]
  • CIS 191 Linux Lab Exercise
    CIS 191 Linux Lab Exercise Lab 9: Backup and Restore Fall 2008 Lab 9: Backup and Restore The purpose of this lab is to explore the different types of backups and methods of restoring them. We will look at three utilities often used for backups and learn the advantages and disadvantages of each. Supplies • VMWare Server 1.05 or higher • Benji VM Preconfiguration • Labs 6 and Labs 7 completed on a pristine Benji VM [root@benji /]# fdisk -l Disk /dev/sda: 5368 MB, 5368709120 bytes 255 heads, 63 sectors/track, 652 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 382 3068383+ 83 Linux /dev/sda2 383 447 522112+ 82 Linux swap / Solaris /dev/sda3 448 511 514080 83 Linux /dev/sda4 512 652 1132582+ 5 Extended /dev/sda5 512 549 305203+ 83 Linux /dev/sda6 550 556 56196 83 Linux /dev/sda7 557 581 200781 83 Linux [root@benji /]# [root@benji /]# mount /dev/sda1 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) /dev/sda5 on /opt type ext3 (rw) /dev/sda3 on /var type ext3 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) /dev/sda7 on /home type ext3 (rw,usrquota) [root@benji /]# cat /etc/fstab LABEL=/1 / ext3 defaults 1 1 devpts /dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults 0 0 LABEL=/opt /opt ext3 defaults 1 2 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 LABEL=/var /var ext3 defaults 1 2 LABEL=SWAP-sda2 swap swap defaults 0 0 LABEL=/home /home ext3 usrquota,defaults 1 2 [root@benji /]# Forum If you get stuck on one of the steps below don’t beat your head against the wall.
    [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]
  • Connecting the Storage System to the Solaris Host
    Configuration Guide for Solaris™ Host Attachment Hitachi Virtual Storage Platform Hitachi Universal Storage Platform V/VM FASTFIND LINKS Document Organization Product Version Getting Help Contents MK-96RD632-05 Copyright © 2010 Hitachi, Ltd., all rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, or stored in a database or retrieval system for any purpose without the express written permission of Hitachi, Ltd. (hereinafter referred to as “Hitachi”) and Hitachi Data Systems Corporation (hereinafter referred to as “Hitachi Data Systems”). Hitachi Data Systems reserves the right to make changes to this document at any time without notice and assumes no responsibility for its use. This document contains the most current information available at the time of publication. When new and/or revised information becomes available, this entire document will be updated and distributed to all registered users. All of the features described in this document may not be currently available. Refer to the most recent product announcement or contact your local Hitachi Data Systems sales office for information about feature and product availability. Notice: Hitachi Data Systems products and services can be ordered only under the terms and conditions of the applicable Hitachi Data Systems agreement(s). The use of Hitachi Data Systems products is governed by the terms of your agreement(s) with Hitachi Data Systems. Hitachi is a registered trademark of Hitachi, Ltd. in the United States and other countries. Hitachi Data Systems is a registered trademark and service mark of Hitachi, Ltd.
    [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]
  • 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]
  • Managing File Systems in Oracle® Solaris 11.4
    ® Managing File Systems in Oracle Solaris 11.4 Part No: E61016 November 2020 Managing File Systems in Oracle Solaris 11.4 Part No: E61016 Copyright © 2004, 2020, Oracle and/or its affiliates. License Restrictions Warranty/Consequential Damages Disclaimer 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. Warranty Disclaimer 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. Restricted Rights Notice 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
    [Show full text]
  • Unionfs: User- and Community-Oriented Development of a Unification File System
    Unionfs: User- and Community-Oriented Development of a Unification File System David Quigley, Josef Sipek, Charles P. Wright, and Erez Zadok Stony Brook University {dquigley,jsipek,cwright,ezk}@cs.sunysb.edu Abstract If a file exists in multiple branches, the user sees only the copy in the higher-priority branch. Unionfs allows some branches to be read-only, Unionfs is a stackable file system that virtually but as long as the highest-priority branch is merges a set of directories (called branches) read-write, Unionfs uses copy-on-write seman- into a single logical view. Each branch is as- tics to provide an illusion that all branches are signed a priority and may be either read-only writable. This feature allows Live-CD develop- or read-write. When the highest priority branch ers to give their users a writable system based is writable, Unionfs provides copy-on-write se- on read-only media. mantics for read-only branches. These copy- on-write semantics have lead to widespread There are many uses for namespace unifica- use of Unionfs by LiveCD projects including tion. The two most common uses are Live- Knoppix and SLAX. In this paper we describe CDs and diskless/NFS-root clients. On Live- our experiences distributing and maintaining CDs, by definition, the data is stored on a read- an out-of-kernel module since November 2004. only medium. However, it is very convenient As of March 2006 Unionfs has been down- for users to be able to modify the data. Uni- loaded by over 6,700 unique users and is used fying the read-only CD with a writable RAM by over two dozen other projects.
    [Show full text]
  • We Get Letters Sept/Oct 2018
    SEE TEXT ONLY WeGetletters by Michael W Lucas letters@ freebsdjournal.org tmpfs, or be careful to monitor tmpfs space use. Hey, FJ Letters Dude, Not that you’ll configure your monitoring system Which filesystem should I use? to watch tmpfs, because it’s temporary. And no matter what, one day you’ll forget —FreeBSD Newbie that you used memory space as a filesystem. You’ll stash something vital in that temporary space, then reboot. And get really annoyed Dear FreeBSD Newbie, when that vital data vanishes into the ether. First off, welcome to FreeBSD. The wider com- Some other filesystems aren’t actively terrible. munity is glad to help you. The device filesystem devfs(5) provides device Second, please let me know who told you to nodes. Filesystems that can’t store user data are start off by writing me. I need to properly… the best filesystems. But then some clever sysad- “thank” them. min decides to hack on /etc/devfs.rules to Filesystems? Sure, let’s talk filesystems. change the standard device nodes for their spe- Discussing which filesystem is the worst is like cial application, or /etc/devd.conf to create or debating the merits of two-handed swords as reconfigure device nodes, and the whole system compared to lumberjack-grade chainsaws and goes down the tubes. industrial tulip presses. While every one of them Speaking of clever sysadmins, now and then has perfectly legitimate uses, in the hands of the people decide that they want to optimize disk novice they’re far more likely to maim everyone space or cut down how many copies of a file involved.
    [Show full text]
  • File Systems
    “runall” 2002/9/24 page 305 CHAPTER 10 File Systems 10.1 BASIC FUNCTIONS OF FILE MANAGEMENT 10.2 HIERARCHICAL MODEL OF A FILE SYSTEM 10.3 THE USER’S VIEW OF FILES 10.4 FILE DIRECTORIES 10.5 BASIC FILE SYSTEM 10.6 DEVICE ORGANIZATION METHODS 10.7 PRINCIPLES OF DISTRIBUTED FILE SYSTEMS 10.8 IMPLEMENTING DISTRIBUTED FILE SYSTEM Given that main memory is volatile, i.e., does not retain information when power is turned off, and is also limited in size, any computer system must be equipped with secondary memory on which the user and the system may keep information for indefinite periods of time. By far the most popular secondary memory devices are disks for random access purposes and magnetic tapes for sequential, archival storage. Since these devices are very complex to interact with, and, in multiuser systems are shared among different users, operating systems (OS) provide extensive services for managing data on secondary memory. These data are organized into files, which are collections of data elements grouped together for the purposes of access control, retrieval, and modification. A file system is the part of the operating system that is responsible for managing files and the resources on which these reside. Without a file system, efficient computing would essentially be impossible. This chapter discusses the organization of file systems and the tasks performed by the different components. The first part is concerned with general user and implementation aspects of file management emphasizing centralized systems; the last sections consider extensions and methods for distributed systems. 10.1 BASIC FUNCTIONS OF FILE MANAGEMENT The file system, in collaboration with the I/O system, has the following three basic functions: 1.
    [Show full text]