Chapter 40 File System Implementation Chien-Chung Shen CIS, UD cshen@cis.udel.edu

Learning by Example A simple file system implementation vsfs (Very Simple File System) a simplified version of Unix file system features include on-disk structures, access methods, and various policies File system is pure software so that no special hardware are added for better performance; however, need to understand and take advantage of device characteristics to make sure file systems work well e.g., AFS -> ZFS with different data structures and features (pros and cons): learning via case studies

Mental Model of FS Mental models are what you are really trying to develop when learning about systems Mental model of file systems include answers to questions like what on-disk structures store the file system’s data and metadata? what happens when a process opens a file? which on-disk structures are accessed during a read or write?

The Way to Think Two aspects: object-oriented view data structures, e.g., what types of on-disk structures are utilized by file system to organize its data and metadata (e.g., array of blocks or tree-based structure) access methods, e.g., how system calls are mapped onto the data structures (e.g., which structures are read during the execution of a particular system call)

Overall Organization (1) Overall on-disk organization of the data structures of the vsfs file system disk is divided into a serious of equal-sized blocks e.g., a small disk is divided into 64 “4KB blocks” 56-block “data region” for user data

Overall Organization (2) Metadata [stored in inode] tracks each file (its data blocks, owner, access rights, modify time, etc.) inode table on disk (5*16 “256-byte inodes”) Need to track whether inodes and data blocks are free or allocated (allocation structures) free list or bitmap (data bitmap and inode bitmap)

Overall Organization (3) Superblock: contains information about this file system, including how many inodes and data blocks are in the file system (80 and 56, respectively), where the inode table begins (block 3), etc. When mounting file system, OS reads the superblock first to initialize various parameters

File Organization: inode (1) “Index node” holding a file’s metadata Inode table of 5 “4KB blocks” To read inode number 32, calculate offset into inode region (32*sizeof(inode) = 8192), add it to the start address of the inode table on disk (12KB) to get 20KB

File Organization: inode (2) Disks are not byte addressable, but rather consist of many addressable sectors, usually 512 bytes. Thus, to fetch the block of inodes that contains inode 32, file system issues a read to sector 40 (20*1024/512) to fetch the desired inode block blk = (inumber * sizeof(inode_t)) / blockSize; sector = ((blk * blockSize) + inodeStartAddr) / sectorSize;

Where Data Blocks Are One option: have one or more direct pointers (disk addresses) inside the inode, each refers to one disk block Limited file size Multi-level index indirect pointers: instead of pointing to a block that contains user data, it points to a block that contains more pointers, each of which point to user data e.g., 4 KB block and 4-byte disk addresses  (12+1024)*4K double indirect pointers triple indirect pointers

Multi-Level Index

Directory Organization Contains a list of (entry name, inode number) pairs for each file or directory in a given directory, there is a string and a number in the data block(s) of the directory For each string, there may also be a length (assuming variable-sized names) assume a directory dir (inode number 5) has three files in it (foo, bar, and foobar), and their inode numbers are 12, 13, and 24 respectively inum | reclen | strlen | name 5 4 2 . 2 4 3 .. 12 4 4 foo 13 4 4 bar 24 8 7 foobar