DOCSLIB.ORG

Filesystems: FAT, FFS, NTFS

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Filesystems: FAT, FFS, NTFS CS162: Operating Systems and Systems Programming Lecture 24: Filesystems: FAT, FFS, NTFS !" July 201$ Charles &eiss %ttps://cs162.eecs.ber*eley(edu' +uilding a File System File System: Layer of OS that transforms block interface of disks (or other block devices) into Files, Directories, etc. File System Components ― 0isk Management: collecting disk )locks into files ― aming: Interface to find files )y name, not by blocks ― Protection: Layers to keep data secure ― &elia)ility'0urability: 4eeping o, files dura)le despite crashes, media failures, attacks, etc 2 Recall: Building a File System -2) 5ser vs. System 6ie7 of a File ― 5ser’s vie7: ● 0ura)le Data Structures ― System8s vie7 (system call interface/: ● Collection o, Bytes -5 39/ ● 0oesn’t matter to system w%at kind o, data structures you 7ant to store on dis*: ― System8s vie7 (inside OS/: ● Collection o, bloc*s (a )loc* is a logical trans,er unit, w%ile a sector is t%e p%ysical trans,er unit/ ● +loc* si;e >= sector si;e; in 5 39, bloc* si;e is 44+ ! FAT (File Allocation Table) FAT Disk Blocks 0: 0: Simple way to store blocksfile number of a file: linked list 31: File 31, Block 0 File 31, Block 1 File number is the first block FAT contains pointers to the next block for each block File 31, Block 2 ― One entry for each data )loc* N-1: N-1: 4 FAT (File Allocation Table) FAT Disk Blocks 0: 0: file number Assume (for no7/ we have a 7ay to translate a path to a 31: File 31, Block 0 File 31, Block 1 ?2le number@ ABample: 2le_read 31, < 2, x< ― IndeB into FAT 7ith file num)er ― Follo7 linked list to block 2 o, the file File 31, Block 2 ― &ead the block from disk into mem N-1: N-1: $ FAT Properties FAT Disk Blocks 0: 0: File is collection o, dis* file number bloc*s 31: File 31, Block 0 FAT is lin*ed list 1E1 7ith File 31, Block 1 bloc*s File um)er is indeB o, first bloc* list ,or the file File offset -o = +:x / free Follo7 list to get bloc* G File 31, Block 2 Unused bloc*s = FAT ,ree list N-1: N-1: mem 6 Storing the FAT FAT Disk Blocks 0: 0: 2le number On disk 7%en system is s%utdown File 31, Block 0 ― 31: FiBed, 7ellE*nown location File 31, Block 1 File 63, Block 1 !o"ied in memory when runnin% ― 1akes accesses, updates ,ast ― Ot%erwise lots of disk seeking File 31, Block 3 File 63, Block 0 to locate t%e )loc*s o, a 2le ,ree 63: File 31, Block 2 2le descriptor 2 number N-1: N-1: H FAT Setup FAT Disk Blocks 0: 0: Format a new FAT drive? File 31, Block 0 File 31, Block 1 Lin* up the free list ,ree File 63, Block 1 ( File 31, Block 3 ( File 63, Block 0 ( File 31, Block 2 N-1: N-1: I FAT Assessment FAT Disk Blocks 0: 0: 2le number all over the place 5sed File 31, Block 0 ― 31: 0OS File 31, Block 1 ― Windows -sometimes) File 63, Block 1 ― T%umb 0ri.es &eally sim"le File 31, Block 3 File 63, Block 0 ,ree 63: ot muc% else in its fa.or((( File 31, Block 2 ― &andom access slo7 ― File creation slo7 N-1: N-1: K Lhat about the DirectoryJ File containing DfileCname: 2le_num)er< mappings Free space for new entries 3n FAT: attri)utes kept in directory (:::/ Eac% directory a linked list of entries L%ere do you find root directory ( “'@ )J 10 Directory Structure (Con8t) Mo7 many disk accesses to resol.e “/my/)ook'count”J ― Read in file %eader for root (fixed spot on dis*/ ― Read in first data )loc* ,or root ● Table o, 2le name/indeB pairs. Search linearly – ok since directories typically very small ― Read in file %eader for “my@ ― Read in first data )loc* ,or ?my@> search ,or ?)oo*@ ― Read in file %eader for “boo*@ ― Read in first data )loc* ,or ?boo*@> searc% ,or ?count@ ― Read in file %eader for “count@ Current working directory: Per-address-space pointer to a directory (2le #) used for resol.ing file names ― Allows user to speci,y relati.e filename instead o, absolute pat% (say CW0=?'my')oo*@ can resolve ?count@/ 11 +ig FAT security holes FAT %as no access rights FAT %as no %eader in the file blocks Just gives and index into the FAT ― -file num)er = block num)er) 12 Designing Better Filesystems Question: What 7ill they )e used forJ 13 Ampirical Characteristics of Files 1ost 2les are small 1ost of the space is occupied )y the rare )ig ones 14 So what about a “real” 2le system Meet the inode file_number 15 So what about a “real” 2le system Meet the inode Array on disk at wellE*nown file_number locations Reserved 7%en disk is "formatted" (more later/ 16 +SD Fast File System -1) Original inode format appeared in BS0 4.1 ― Berkeley Standard 0istri)ution UniB File Number is indeB into inode 'rrays Multi-level index structure ― Qreat for little to large files ― Asymmetric tree with fiBed sized blocks 17 +SD Fast File System -2) Metadata associated with the file ― &ather than in the directory that points to it 5 39 FFS: BS0 4.2: Locality Heuristics ― Attempt to allocate files contiguously ― Block group placement ― &eserve space Scalable directory structure 18 An “almost real” file system Pintos: src/filesys'2le.c, inode.c file_number 19 Mow do you find an inode on diskJ Inode is, say, 128 bytes Inode G10"" is 128 ) 1000 bytes into inode array Inode array is fixed location on disk ― A.g. starts at )lock #2 +locks are 4KB? Inode G1000 is in the middle of block G!! (= 2 + 128 S 1000 / 4096) 20 FFS: File Attributes Inode metadata – stored $ithin inode User Qroup K basic access control bits - UGO x RL9 Setuid bit E eBecute at o7ner permissions E rat%er t%an user Qetgid bit 21 E eBecute at group’s permissions FFS: Data Storage Small files: 12 pointers direct to data blocks 0irect pointers 4*+ bloc*s: suTcient ,or files up to 4I4+ 22 FFS: Freespace Management +it vector wit% a bit per storage block Stored at a fixed location on disk 23 Lhere are inodes stored? -1) In early U 39 and 0OS/Windo7s’ FAT 2le system, %eaders/inodes stored in special array in outermost cylinders ― Outermost because ,astest to read ― FiBed size, set when disk is form'tted. 24 Lhere are inodes stored? -1) In early U 39 and 0OS/Windo7s’ FAT 2le system, %eaders/inodes stored in special array in outermost cylinders ― Outermost because ,astest to read ― FiBed size, set when disk is form'tted. Mow does OS *now t%e size/location w%en booting up? Written in fixed location on every filesystem FFS: Called the "superblockP (Sometimes backup copies in case of failure) 25 Lhere are inodes stored? -2) In early U 39 and 0OS/Windo7s’ FAT 2le system, %eaders/inodes stored in special array in outermost cylinders Problem: How do you read a small fileJ ― &ead its inode -outermost cylinders/ ― &ead its data – pro)a)ly ,ar away ― +ots of seek time 26 Logistics Project 3 Design Revie7s Tomorro7 ― You should have already su)mitted your design doc ML3 out 27 +reak 28 Locality: Block Groups File system .olume is divided into a set of block groups ― !lose set of tracks Idea: Low see* times between inode/directories for a file and )locks of a file 29 Locality: Block Groups File data blocks, metadata, and free space are interleaved within block group ― o huge seeks Put directory and its 2les in common bloc* group !" FFS First Fit Block Allocation • Fills in the small holes at the start of block group • Avoids fragmentation, leaves contiguous free space at end 31 Locality: Block Groups FirstE,ree allocation o, ne7 2le bloc* ― Few little holes at start, big seWuential runs at end o, group ― Sequential layout for big files &eserve space in t%e BQ ― 10X ― Makes sure there's seWuential holes for )ig files ― Lets P2rst 2t" be fast – likely to find somet%ing Wuickly 32 Attack of the Rotational Delay Problem: Missing blocks due to rotational delay ― &ead one block, do processing, and read neBt )lock. ― In meantime, disk has continued turning: missed neBt )loc*: ― eed 1 revolution')lock! !! Attack of the Rotational Delay S*ip Sector Trac* Buffer -Molds complete trac*/ Solution 1: S*ip sector positioning (?interlea.ing”/ ― Place the )loc*s from one 2le on e.ery ot%er )lock of a track: give time for processing to o.erlap rotation ― FFS did this Solution 2: Read a%ead: read neBt bloc* right a,ter first – s"ecul'te t%at it will )e needed ― By OS -make larger reWuest/ N reWuires &A1 to %old result of read ― By disk -track buffers/ N reWuires &A1 in the controller ― 1ost modern disk controllers do t%is 34 +SD Fast File System Pros ― ATcient storage ,or )ot% sm'll and l'r%e 2les ― +ocalit# ,or bot% small and large 2les ― +ocalit# ,or metadata and data Cons ― 3neTcient ,or tiny files -a 1 byte 2le requires )ot% an inode and a data bloc*/ ― 3neTcient encoding 7%en 2le is mostly contiguous on dis* -no 7ay to say Pbloc*s 1"26E4"I$P N need to 7rite out eac% bloc* number/ ― Need to reserve 1"E2"X of ,ree space to prevent r'%ment'tion !$ +SD Fast File System Pros ― ATcient storage ,or )ot% sm'll and l'r%e 2les ― +ocalit# ,or bot% small and large 2les ― +ocalit# ,or metadata and data Cons ― 3neTcient ,or tiny files -a 1 byte 2le requires )ot% an inode and a data bloc*/ ― 3neTcient encoding 7%en 2le is mostly contiguous on dis* -no 7ay to say Pbloc*s 1"26E4"I$P N need to 7rite out eac% bloc* number/ ― Need to reserve 1"E2"X of ,ree space to prevent r'%ment'tion 36 Linux Axample: Ext2/!'4 Disk Layout Disk di.ided into bloc* groups ― Li*e FFS, pro.ides locality ― Each group %as t7o )lockE si;ed bitmaps -,ree blocks/inodes/ Actual Inode structure similar to 4.2+SD FFS ― 7it% 12 direct pointers ABt!: EBt2 w'#ournaling ― Better durability – more on t%at later Axample: create a file1.dat /dir1/ under in Ext! !H A bit more on directories /usr 5niB: Directories are just files Contents: list o (file n'me, file number- .usr.lib .usr.lib/*3 "'irs FFS: Lin*ed list li*e FAT .usr.lib4.3/foo &ead'7ritten
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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • A Directory Structure for TEX Files TUG Working Group on a TEX Directory Structure (TWG-TDS) Version 1.1 June 23, 2004
    A Directory Structure for TEX Files TUG Working Group on a TEX Directory Structure (TWG-TDS) version 1.1 June 23, 2004 Copyright c 1994, 1995, 1996, 1997, 1998, 1999, 2003, 2004 TEX Users Group. Permission to use, copy, and distribute this document without modification for any purpose and without fee is hereby granted, provided that this notice appears in all copies. It is provided “as is” without expressed or implied warranty. Permission is granted to copy and distribute modified versions of this document under the condi- tions for verbatim copying, provided that the modifications are clearly marked and the document is not represented as the official one. This document is available on any CTAN host (see Appendix D). Please send questions or suggestions by email to [email protected]. We welcome all comments. This is version 1.1. Contents 1 Introduction 2 1.1 History . 2 1.2 The role of the TDS ................................... 2 1.3 Conventions . 3 2 General 3 2.1 Subdirectory searching . 3 2.2 Rooting the tree . 4 2.3 Local additions . 4 2.4 Duplicate filenames . 5 3 Top-level directories 5 3.1 Macros . 6 3.2 Fonts............................................ 8 3.3 Non-font METAFONT files................................ 10 3.4 METAPOST ........................................ 10 3.5 BIBTEX .......................................... 11 3.6 Scripts . 11 3.7 Documentation . 12 4 Summary 13 4.1 Documentation tree summary . 14 A Unspecified pieces 15 A.1 Portable filenames . 15 B Implementation issues 16 B.1 Adoption of the TDS ................................... 16 B.2 More on subdirectory searching . 17 B.3 Example implementation-specific trees .
    [Show full text]
  • Answers to Even-Numbered Exercises
    4 Answers to Even-numbered Exercises 1. 2. List the commands you can use to perform these operations: a. Make your home directory the working directory b. Identify the working directory a. cd; b. pwd 3. 4. The df utility displays all mounted filesystems along with information about each. Use the df utility with the –h (human-readable) option to answer the following questions. $ df -h Filesystem Size Used Avail Capacity Mounted on /dev/disk2s10 20G 2.6G 17G 13% / devfs 114K 114K 0B 100% /dev fdesc 1.0K 1.0K 0B 100% /dev <volfs> 512K 512K 0B 100% /.vol /dev/disk0s9 77G 37G 39G 49% /Volumes/Scratch /dev/disk1s9 25G 16G 9.5G 63% /Volumes/Sys /dev/disk2s12 94G 43M 94G 0% /Volumes/New /dev/disk1s10 86G 71G 15G 83% /Volumes/Home automount -nsl [223] 0B 0B 0B 100% /Network automount -fstab [232] 0B 0B 0B 100% /automount/Servers automount -static [232] 0B 0B 0B 100% /automount/static a. How many filesystems are mounted on your Mac OS X system? b. Which filesystem stores your home directory? c. Assuming that your answer to exercise 4a is two or more, attempt to create a hard link to a file on another filesystem. What error message do you get? What happens when you attempt to create a symbolic link to the file instead? 1 2 Answers to Even-numbered Exercises Following are sample answers to these questions. Your answers will be different because your filesystem is different. a. five; b. /dev/disk2s10; c. ln: xxx: Cross-device link. No problem creating a cross-device symbolic link.
    [Show full text]
  • File System Layout
    File Systems Main Points • File layout • Directory layout • Reliability/durability Named Data in a File System index !le name directory !le number structure storage o"set o"set block Last Time: File System Design Constraints • For small files: – Small blocks for storage efficiency – Files used together should be stored together • For large files: – ConCguous allocaon for sequenCal access – Efficient lookup for random access • May not know at file creaon – Whether file will become small or large File System Design Opons FAT FFS NTFS Index Linked list Tree Tree structure (fixed, asym) (dynamic) granularity block block extent free space FAT array Bitmap Bitmap allocaon (fixed (file) locaon) Locality defragmentaon Block groups Extents + reserve Best fit space defrag MicrosoS File Allocaon Table (FAT) • Linked list index structure – Simple, easy to implement – SCll widely used (e.g., thumb drives) • File table: – Linear map of all blocks on disk – Each file a linked list of blocks FAT MFT Data Blocks 0 1 2 3 !le 9 block 3 4 5 6 7 8 9 !le 9 block 0 10 !le 9 block 1 11 !le 9 block 2 12 !le 12 block 0 13 14 15 16 !le 12 block 1 17 18 !le 9 block 4 19 20 FAT • Pros: – Easy to find free block – Easy to append to a file – Easy to delete a file • Cons: – Small file access is slow – Random access is very slow – Fragmentaon • File blocks for a given file may be scaered • Files in the same directory may be scaered • Problem becomes worse as disk fills Berkeley UNIX FFS (Fast File System) • inode table – Analogous to FAT table • inode – Metadata • File owner, access permissions,
    [Show full text]