CS 4284 Systems Capstone

1. CS 4284Systems Capstone Disks & File Systems Godmar Back

2. Filesystems

3. File Abstraction Byte oriented Names Access protection Consistency guarantees Disk Abstraction Block oriented Block #s No protection No guarantees beyond block write Files vs Disks CS 4284 Spring 2013

4. Filesystem Requirements • Naming • Should be flexible, e.g., allow multiple names for same files • Support hierarchy for easy of use • Persistence • Want to be sure data has been written to disk in case crash occurs • Sharing/Protection • Want to restrict who has access to files • Want to share files with other users CS 4284 Spring 2013

5. FS Requirements (cont’d) • Speed & Efficiency for different access patterns • Sequential access • Random access • Sequential is most common & Random next • Other pattern is Keyed access (not usually provided by OS) • Minimum Space Overhead • Disk space needed to store metadata is lost for user data • Twist: all metadata that is required to do translation must be stored on disk • Translation scheme should minimize number of additional accesses for a given access pattern • Harder than, say page tables where we assumed page tables themselves are not subject to paging! CS 4284 Spring 2013

6. Filesystems Software Architecture (including in-memory data structures)

7. Overview File Operations: create(), unlink(), open(),read(), write(), close() • Uses names for files • Views files as sequence of bytes File System Must implement translation (file name, file offset) (disk id, disk sector, sector offset) Must manage free space on disk Buffer Cache Uses disk id + sector indices Device Driver CS 4284 Spring 2013

8. The Big Picture File Data Per-process file descriptor table Data structures to keep track of open files struct file inode + position + … struct dir inode + position struct inode Buffer Cache … 5 4 3 2 1 0 Directory Data File Descriptors(inodes) ? PCB Filesystem Information Open file table Cached data and metadata in buffer cache On-DiskData Structures CS 4284 Spring 2013

9. Steps in Opening & Reading a File • Lookup (via directory) • find on-disk file descriptor’s block number • Find entry in open file table (struct inode list in Pintos) • Create one if none, else increment ref count • Find where file data is located • By reading on-disk file descriptor • Read data & return to user CS 4284 Spring 2013

10. Open File Table • inode – represents file • at most 1 in-memory instance per unique file • #number of openers & other properties • file – represents one or more processes using an file • With separate offsets for byte-stream • dir – represents an open directory file • Generally: • None of data in OFT is persistent • Reflects how processes are currently using files • Lifetime of objects determined by open/close • Reference counting is used CS 4284 Spring 2013

11. File Descriptors (“inodes”) • Term “inode” can refer to 3 things: • in-memory inode • Store information about an open file, such as how many openers, corresponds to on-disk file descriptor • on-disk inode • Region on disk, entry in file descriptor table, that stores persistent information about a file – who owns it, where to find its data blocks, etc. • on-disk inode, when cached in buffer cache • A bytewise copy of 2. in memory • Q.: Should in-memory inode store a pointer to cached on-disk inode? (Answer: No.) CS 4284 Spring 2013

12. Filesystems On-Disk Data Structures and Allocation Strategies

13. Filesystem Information Free Block Map0100011110101010101 Super Block • Contains “superblock”stores information such assize of entire filesystem, etc. • Location of file descriptor table & free map • Free Block Map • Bitmap used to find free blocks • Typically cached in memory • Superblock & free map often replicated in different positions on disk CS 4284 Spring 2013

14. File Allocation Strategies • Contiguous allocation • Linked files • Indexed files • Multi-level indexed files CS 4284 Spring 2013

15. Contiguous Allocation File A File B • Idea: allocate files in contiguous blocks • File Descriptor = (first block, length) • Good sequential & random access • Problems: • hard to extend files – may require expensive compaction • external fragmentation • analogous to segmentation-based VM • Pintos’s baseline implementation does this CS 4284 Spring 2013

16. Linked Files File APart 1 File B Part 1 File APart 2 File B Part 2 • Idea: implement linked list • either with variable sized blocks • or fixed sized blocks (“clusters”) • Solves fragmentation problem, but now • need lots of seeks for sequential accesses and random accesses • unreliable: lose first block, may lose file • Solution: keep linked list in memory • DOS: FAT File Allocation Table CS 4284 Spring 2013

17. DOS FAT • FAT stored at beginning of disk & replicated for redundancy • FAT cached in memory • Size: n-bit entries, m-bit blocks  2^(m+n) limit • n=12, 16, 28 • m=9 … 15 (0.5KB-32KB) • As disk size grows, m & n must grow • Growth of n means larger in-memory table CS 4284 Spring 2013

18. DOS FAT Scalability Limits • FAT-12 uses 12 bit entries, max of 4096 clusters • FAT-16: 65536 clusters, FAT-32 uses 28bits, so theoretical max of 2^28 (1 Gi) clusters • Floppy disk, say 1.4MB; FAT-12, 1K clusters, need 1,400 entries, 2 bytes each -> 2.8KB • Modern disk, say ~500 GB (~2^41 bytes) • At 4 KB cluster size, would need 2^29 entries. Each entry at 4 bytes, would need 2^31 bytes, or 2GB, RAM just to hold the FAT. • At 32 KB cluster size, would need only 1/8, but still 256MB RAM to hold FAT; simple operations, such as determining how much space is free on disk, require reading entire FAT CS 4284 Spring 2013

19. Blocksize Trade-Offs • Chart above assumes all files are 2KB in size (observed median file size is about 2KB) • Larger blocks: faster reads (because seeks are amortized & more bytes per transfer) • More wastage (2KB file in 32KB block means 15/16th are unused) • Source: Tanenbaum, Modern Operating Systems CS 4284 Spring 2013

20. Indexed Allocation File AIndex File APart 1 File APart 2 File APart 3 • Single-index: specify maximum filesize, create index array, then note blocks in index • Random access ok – one translation step • Sequential access requires more seeks – depending on contiguous allocation • Drawback: hard to grow beyond maximum CS 4284 Spring 2013

21. Multi-Level Indices 1 • Used in Unix & (possibly) Pintos (P4) 2 1 2 3 ..N FLI SLITLI Direct Blocks N N+1 N+I index Indirect Block index N+I+1 DoubleIndirect Block index2 index TripleIndirect Block index3 index2 N+I+I2 index CS 4284 Spring 2013

22. Logical View (Per File) offset in file Inode Index Data Index2 0 1 2 3 4 5 6 7 12 13 14 20 21 27 28 34 35 Physical View (On Disk) (ignoring other files) sector numbers on disk CS 4284 Spring 2013

23. 14 … 15 16 17 18 19 1 … 6 … 2 7 3 8 4 9 5 10 … 13 12 11 20 27 34 -1 -1 Logical View (Per File) offset in file Inode Index Data Index2 0 1 2 3 4 5 6 7 12 13 14 20 21 27 28 34 35 Physical View (On Disk) (ignoring other files) sector numbers on disk CS 4284 Spring 2013

24. Multi-Level Indices • If filesz < N * BLKSIZE, can store all information in direct block array • Biased in favor of small files (ok because most files are small…) • Assume index block stores I entries • If filesz < (I + N) * BLKSIZE, 1 indirect block suffices • Q.: What’s the maximum size before we need triple-indirect block? • Q.: What’s the per-file overhead (best case, worst case?) CS 4284 Spring 2013

25. Extents • Index-tree based scheme avoids external fragmentation, and is efficient for small files, but incurs relatively high meta-data overhead for large files • Extents can improve that – store (bnum, length) pair to denote that file occupies blocks [bnum, … , bnum+length-1] • But complicates offset -> sector translation • Used in ext4. CS 4284 Spring 2013

26. Storing Inodes Unix v7, BSD 4.3 FFS (BSD 4.4) Cylindergroups have superblock+bitmap+inode list+file space Try to allocate file & inode in same cylinder group to improve access locality Superblock I0 I1I2 I3I4 ….. Rest of disk for files & directories CGi SB1 I0 I1… Files … SB2 I3I4 ….. Files … SB3 I8I9 ….. Files … CS 4284 Spring 2013

27. Positioning Inodes Putting inodes in fixed place makes finding inodes easier Can refer to them simply by inode number After crash, there is no ambiguity as to what are inodes vs. what are regular files Disadvantage: limits the number of files per filesystem at creation time Use “df –ih” on Linux/ext3 to see how many inodes are used/free CS 4284 Spring 2013

28. Filesystems Directories and Name Resolution

29. Directories Need to find file descriptor (inode), given a name Approaches: Single directory (old PCs), Two-level approaches with 1 directory per user Now exclusively hierarchical approaches: File system forms a tree (or DAG) How to tell regular file from directory? Set a bit in the inode Data Structures Linear list of (inode, name) pairs B-Trees that map name -> inode Combinations thereof CS 4284 Spring 2013

30. Using Linear Lists Advantage: (relatively) simple to implement Disadvantages: Scan makes lookup (& delete!) really slow for large directories Could cause fragmentation (though not a problem in practice) inode # 23 multi-oom 15 sample.txt offset 0 CS 4284 Spring 2013

31. Using B+-Trees Advantages: Scalable to large number of files: in growth, in lookup time Disadvantage: Complex Overhead for small directories (some filesystems switch to B+-Tree only for large directories) Note: some filesystems use B+-Tree not only for directory files, but for block indexes as well. HFS’s ‘catalog’ – single B+-Tree that stores inodes + directories. Also done in NTFS, XFS & Reiserfs, ZFS, and Btrfs Source: Wikipedia) CS 4284 Spring 2013

32. Absolute Paths How to resolve a path name such as “/usr/bin/ls”? Split into tokens using “/” separator Find inode corresponding to root directory (how? Use fixed inode # for root) (*) Look up “usr” in root directory, find inode If not last component in path, check that inode is a directory. Go to (*), looking for next comp If last component in path, check inode is of desired type, return CS 4284 Spring 2013

33. Name Resolution Must have a way to scan an entire directory without other processes interfering -> need a “lock” function But don’t need to hold lock on /usr when scanning /usr/bin Directories can only be removed if they’re empty Requires synchronization also Most OS cache translations in “namei” cache – maps absolute pathnames to inode Must keep namei cache consistent if files are deleted CS 4284 Spring 2013

34. Current Directory Relative pathnames are resolved relative to current directory Provides default context Every process has one in Unix/Pintos chdir(2) changes current directory cd tmp; ls; pwd vs (cd tmp; ls); pwd lookup algorithm the same, except starts from current dir process should keep current directory open current directory inherited from parent CS 4284 Spring 2013

35. Hard & Soft Links Provides aliases (different names) for a file Hard links: (Unix: ln) Two independent directory entries have the same inode number, refer to same file Inode contains a reference count Disadvantage: alias only possible with same filesystem Soft links: (Unix: ln –s) Special type of file (noted in inode); content of file is absolute or relative pathname – stored inside inode instead of direct block list Windows: “junctions” & “shortcuts” CS 4284 Spring 2013