Class 20 CS 439 28 March 2013 On the board ------------ 1. Last time 2. File systems --------------------------------------------------------------------------- 1. Last time finished concurrency notes from last time have a summary of the concurrency unit. you may find that useful. began file systems 2. file systems A. [last time] intro B. [last time] files C. [last time] implementing files 1. [last time] contiguous 2. [last time] linked files 3. FAT 4. indexed files D. Directories E. FS performance F. mmap C. implementing files [....] 3. modification of linked files: FAT --keep link structure in memory --in fixed-size "FAT" (file allocation table) --pointer chasing now happens in RAM [DRAW PICTURE] --example: MS-DOS (and iPods, MP3 players, digital cameras) +: no need to maintain separate free list (table says what's free) +: low space overhead -: maximum size limited. 64K entries 512 byte blocks --> 32MB max file system bigger blocks bring advantages and disadvantages, and ditto a bigger table note: to guard against bad sectors, better store multiple copies of FAT on the disk!! 4. indexed files [DRAW PICTURE] --Each file has an array holding all of its block pointers --like a page table, so similar issues crop up --Allocate this array on file creation --Allocate blocks on demand (using free list) +: sequential and random access are both easy -: need to somehow store the array --large possible file size --> lots of unused entries in the block array --large actual block size --> huge contiguous disk chunk needed --solve the problem the same way we did for page tables: [............] [..........] [.........] [ block block block] --okay, so now we're not wasting disk blocks, but what's the problem? (answer: equivalent issues as for page tables: here, it's extra disk accesses to look up the blocks) 5. indexed files, take two --classic Unix file system --inode contains: permisssions times for file access, file modification, and inode-change link count (# directories containing file) ptr 1 --> data block ptr 2 --> data block ptr 3 --> data block ..... ptr 11 --> indirect block ptr --> ptr --> ptr --> ptr --> ptr --> ptr 12 --> indirect block ptr 13 --> double indirect block ptr 14 --> triple indirect block +: Simple, easy to build, fast access to small files +: Maximum file length can be enormous, with multiple levels of indirection -: worst case # of accesses pretty bad -: worst case overhead (such as 11 block file) pretty bad -: Because you allocate blocks by taking them off unordered freelist, meta data and data get strewn across disk Notes about inodes: --stored in a fixed-size array --Size of array fixed when disk is initialized; can't be changed --Multiple inodes in a disk block --Lives in known location, originally at one side of disk, now lives in pieces across disk (helps keep metadata close to data) --The index of an inode in the inode array is called an ***i-number*** --Internally, the OS refers to files by i-number --When a file is opened, the inode brought in memory --Written back when modified and file closed or time elapses D. Directories --Problem: "Spend all day generating data, come back the next morning, want to use it." F. Corbato, on why files/dirs invented. --Approach 0: Have users remember where on disk their files are --like remembering your social security or bank account # --yuck. (people want human-friendly names.) --So use directories to map names to file blocks, somehow --But what is in directory? --A short history of directories --Approach 1: Single directory for entire system --Put directory at known location on disk --Directory contains pairs --If one user uses a name, no one else can --Many ancient personal computers work this way --Approach 2: Single directory for each user --Still clumsy, and "ls" on 10,000 files is a real pain --(But some oldtimers still work this way) --Approach 3: Hierarchical name spaces. --Allow directory to map names to files ***or other dirs*** --File system forms a tree (or graph, if links allowed) --Large name spaces tend to be hierarchical --examples: IP addresses (will come up in networking unit), domain names, scoping in programming languages, etc.) --more generally, the concept of hierarchy is everywhere in computer systems --Hierarchial Unix --used since CTSS (1960s), and Unix picked it up and used it nicely --structure like: "/" bin cdrom dev sbin tmp awk chmod .... --directories stored on disk just like regular files --here's the data in a directory file; this data is in the *data blocks* of the directory: [] .... --i-node for directory contains a special flag bit --only special users can write directory files --key point: i-number might reference another directory --this neatly turns the FS into a hierarchical tree, with almost no work --another nice thing about this: if you speed up file operations, you also speed up directory operations, because directories are just like files --bootstrapping: where do you start looking? --root dir always inode #2 (0 and 1 reserved) --and, voila, we have a namespace! --special names: "/", ".", ".." --given those names, we need only two operations to navigate the entire name space: --"cd name": (change context to directory "name") --"ls": (list all names in current directory) --example: [DRAW PICTURE] --links: --hard link: multiple dir entries point to same inode; inode contains refcount "ln a b": creates a synonym ("b") for file ("a") --how do we avoid cycles in the graph? (answer: can't hard link to directories) --soft link: synonym for a *name* "ln -s /d/a b": --creates a new inode, not just a new directory entry --new inode has "sym link" bit set --contents of that new file: "/d/a" --------------------------------------------------------------------------- thanks to David Mazieres and Mike Dahlin