Presentation is loading. Please wait.

Presentation is loading. Please wait.

CS 5600 Computer Systems Lecture 10: File Systems.

Similar presentations


Presentation on theme: "CS 5600 Computer Systems Lecture 10: File Systems."— Presentation transcript:

1 CS 5600 Computer Systems Lecture 10: File Systems

2 What are We Doing Today? Last week we talked extensively about hard drives and SSDs – How they work – Performance characteristics This week is all about managing storage – Disks/SSDs offer a blank slate of empty blocks – How do we store files on these devices, and keep track of them? – How do we maintain high performance? – How do we maintain consistency in the face of random crashes? 2

3 Partitions and Mounting Basics (FAT) inodes and Blocks (ext) Block Groups (ext2) Journaling (ext3) Extents and B-Trees (ext4) Log-based File Systems 3

4 Building the Root File System One of the first tasks of an OS during bootup is to build the root file system 1. Locate all bootable media – Internal and external hard disks – SSDs – Floppy disks, CDs, DVDs, USB sticks 2. Locate all the partitions on each media – Read MBR(s), extended partition tables, etc. 3. Mount one or more partitions – Makes the file system(s) available for access 4

5 MBR Partition 1 (ext3) Partition 2 (swap) Partition 3 (NTFS) Partition 4 (FAT32) The Master Boot Record 5 Address Description Size (Bytes) HexDec. 0x0000Bootstrap code area446 0x1BE446Partition Entry #116 0x1CE462Partition Entry #216 0x1DE478Partition Entry #316 0x1EE494Partition Entry #416 0x1FE510Magic Number2 Total:512 Includes the starting LBA and length of the partition Disk 1 MBR Partition 1 (NTFS) Disk 2

6 Extended Partitions In some cases, you may want >4 partitions Modern OSes support extended partitions 6 Partition 1 (ext3) Partition 2 (swap) Partition 3 (Extended Partition) Partition 4 (FAT32) Disk 1 Logical Partition 1 (NTFS) Logical Partition 2 (NTFS) Extended partitions may use OS-specific partition table formats (meta-data) – Thus, other OSes may not be able to read the logical partitions MBR Ext. Part.

7 Types of Root File Systems Windows exposes a multi-rooted system – Each device and partition is assigned a letter – Internally, a single root is maintained Linux has a single root – One partition is mounted as / – All other partitions are mounted somewhere under / Typically, the partition containing the kernel is mounted as / or C: 7 [cbw@ativ9 ~] df -h FilesystemSizeUsedAvailUse%Mounted on /dev/sda739G14G23G38%/ /dev/sda2296M48M249M16%/boot/efi /dev/sda5127G86G42G68%/media/cbw/Data /dev/sda461G34G27G57%/media/cbw/Windows /dev/sdb11.9G352K1.9G1%/media/cbw/NDSS-2013 1 drive, 4 partitions 1drive, 1 partition

8 Mounting a File System 1.Read the super block for the target file system – Contains meta-data about the file system – Version, size, locations of key structures on disk, etc. 2.Determine the mount point – On Windows: pick a drive letter – On Linux: mount the new file system under a specific directory 8 FilesystemSizeUsedAvailUse%Mounted on /dev/sda5127G86G42G68%/media/cbw/Data /dev/sda461G34G27G57%/media/cbw/Windows /dev/sdb11.9G352K1.9G1%/media/cbw/NDSS-2013

9 Problem: the OS may mount several partitions containing different underlying file systems – It would be bad if processes had to use different APIs for different file systems Linux uses a Virtual File System interface (VFS) – Exposes POSIX APIs to processes – Forwards requests to lower-level file system specific drivers Windows uses a similar system Virtual File System Interface 9

10 VFS Flowchart 10 Kernel Process 1Process 2Process 3 Virtual File System Interface ext3 Driver NTFS Driver FAT32 Driver ext3 Partition NTFS Partition FAT32 Partition Processes (usually) don’t need to know about low- level file system details Relatively simple to add additional file system drivers

11 Mount isn’t Just for Bootup When you plug storage devices into your running system, mount is executed in the background Example: plugging in a USB stick What does it mean to “safely eject” a device? – Flush cached writes to that device – Cleanly unmount the file system on that device 11

12 Partitions and Mounting Basics (FAT) inodes and Blocks (ext) Block Groups (ext2) Journaling (ext3) Extents and B-Trees (ext4) Log-based File Systems 12

13 Status Check At this point, the OS can locate and mount partitions Next step: what is the on-disk layout of the file system? – We expect certain features from a file system Named files Nested hierarchy of directories Meta-data like creation time, file permissions, etc. – How do we design on-disk structures that support these features? 13

14 The Directory Tree Navigated using a path – E.g. /home/amislove/music.mp3 14 home / (root) bin tmp python cbw amislove cs5600

15 Absolute and Relative Paths Two types of file system paths – Absolute Full path from the root to the object Example: /home/cbw/cs5600/hw4.pdf Example: C:\Users\cbw\Documents\ – Relative OS keeps track of the working directory for each process Path relative to the current working directory Examples [working directory = /home/cbw]: – syllabus.docx [  /home/cbw/syllabus.docx] – cs5600/hw4.pdf [  /home/cbw/cs5600/hw4.pdf] –./cs5600/hw4.pdf [  /home/cbw/cs5600/hw4.pdf] –../amislove/music.mp3 [  /home/amislove/music.mp3] 15

16 Files A file is a composed of two components – The file data itself One or more blocks (sectors) of binary data A file can contain anything – Meta-data about the file Name, total size What directory is it in? Created time, modified time, access time Hidden or system file? Owner and owner’s group Permissions: read/write/execute 16

17 File Extensions File name are often written in dotted notation – E.g. program.exe, image.jpg, music.mp3 A file’s extension does not mean anything – Any file (regardless of its contents) can be given any name or extension 17 Rename Graphical shells (like Windows explorer) use extensions to try and match files  programs – This mapping may fail for a variety of reasons Has the data in the file changed from music to an image?

18 More File Meta-Data Files have additional meta-data that is not typically shown to users – Unique identifier (file names may not be unique) – Structure that maps the file to blocks on the disk Managing the mapping from files to blocks is one of the key jobs of the file system 18 Disk

19 Mapping Files to Blocks Every file is composed of >=1 blocks Key question: how do we map a file to its blocks? 19 0 2345 79 1 8 6 [1][4, 5, 7, 8] [6] List of blocks 0234568179 (1, 1) (4, 4) (9, 1) As (start, length) pairs Problem? – Really large files Problem? – Fragmentation – E.g. try to add a new file with 3 blocks

20 Directories Traditionally, file systems have used a hierarchical, tree-structured namespace – Directories are objects that contain other objects i.e. a directory may (or may not) have children – Files are leaves in the tree By default, directories contain at least two entries 20 / (root) bin python... “.” self pointer “..” points the the parents directory

21 More on Directories Directories have associated meta-data – Name, number of entries – Created time, modified time, access time – Permissions (read/write), owner, and group The file system must encode directories and store them on the disk – Typically, directories are stored as a special type of file – File contains a list of entries inside the directory, plus some meta-data for each entry 21

22 Example Directory File 22 23456789 Disk C:\ Windows Users C:\ NameIndexDir?Perms.2Yrwx Windows3Yrwx Users4Yrwx pagefile.sys5Nr 10

23 Directory File Implementation Each directory file stores many entries Key Question: how do you encode the entries? NameIndexDir?Perms.2Yrwx Windows3Yrwx Users4Yrwx pagefile.sys5Nr Unordered List of Entries Good: O(1) to add new entries – Just append to the file Bad: O(n) to search for an entry NameIndexDir?Perms.2Yrwx pagefile.sys5Nr Users4Yrwx Windows3Yrwx Sorted List of Entries Good: O(log n) to search for an entry Bad: O(n) to add new entries – Entire file has the be rewritten Other alternatives: hash tables, B-trees More on B-trees later… In practice, implementing directory files is complicated Example: do filenames have a fixed, maximum length or variable length?

24 File Allocation Tables (FAT) Simple file system popularized by MS-DOS – First introduced in 1977 – Most devices today use the FAT32 spec from 1996 – FAT12, FAT16, VFAT, FAT32, etc. Still quite popular today – Default format for USB sticks and memory cards – Used for EFI boot partitions Name comes from the index table used to track directories and files 24

25 25 Super Block Disk Stores basic info about the file system FAT version, location of boot files Total number of blocks Index of the root directory in the FAT Store file and directory data Each block is a fixed size (4KB – 64KB) Files may span multiple blocks File allocation table (FAT) Marks which blocks are free or in-use Linked-list structure to manage large files

26 23456789 26 Super Block Disk C:\ Windows Users 23456789 Root directory index = 2 C:\ NameIndexDir?Perms.2Yrwx Windows3Yrwx Users4Yrwx pagefile.sys5Nr Directories are special files – File contains a list of entries inside the directory Possible values for FAT entries: – 0 – entry is empty – 1 – reserved by the OS – 1 < N < 0xFFFF – next block in a chain – 0xFFFF – end of a chain

27 Fat Table Entries len(FAT) == Number of clusters on the disk – Max number of files/directories is bounded – Decided when you format the partition The FAT version roughly corresponds to the size in bits of each FAT entry – E.g. FAT16  each FAT entry is 16 bits – More bits  larger disks are supported 27

28 Fragmentation Blocks for a file need not be contiguous 28 68676564 63626160 59585756 061670 580 0xFF FF 0 06500 68676564 63626160 59585756 FAT Blocks Start End Possible values for FAT entries: 0 – entry is empty 1 < N < 0xFFFF – next block in a chain 0xFFFF – end of a chain

29 FAT: The Good and the Bad The Good – FAT supports: – Hierarchical tree of directories and files – Variable length files – Basic file and directory meta-data The Bad – At most, FAT32 supports 2TB disks – Locating free chunks requires scanning the entire FAT – Prone to internal and external fragmentation Large blocks  internal fragmentation – Reads require a lot of random seeking 29

30 Lots of Seeking Consider the following code: int fd = open(“my_file.txt”, “r”); int r = read(fd, buffer, 1024 * 4 * 4); // 4 4KB blocks 30 68676564 63626160 59585756 605900 5756063 0xFF FF 0 67 68676564 63626160 59585756 FAT Blocks FAT may have very low spatial locality, thus a lot of random seeking

31 Partitions and Mounting Basics (FAT) inodes and Blocks (ext) Block Groups (ext2) Journaling (ext3) Extents and B-Trees (ext4) Log-based File Systems 31

32 Status Check At this point, we have on-disk structures for: – Building a directory tree – Storing variable length files But, the efficiency of FAT is very low – Lots of seeking over file chains in FAT – Only way to identify free space is to scan over the entire FAT Linux file system uses more efficient structures – Extended File System (ext) uses index nodes (inodes) to track files and directories 32

33 Size Distribution of Files FAT uses a linked list for all files – Simple and uniform mechanism – … but, it is not optimized for short or long files Question: are short or long files more common? – Studies over the last 30 years show that short files are much more common – 2KB is the most common file size – Average file size is 200KB (biased upward by a few very large files) Key idea: optimize the file system for many small files 33

34 34 Super block, storing: Size and location of bitmaps Number and location of inodes Number and location of data blocks Index of root inodes Data blocks (4KB each) Bitmap of free & used data blocks Table of inodes Each inode is a file/directory Includes meta-data and lists of associated data blocks Bitmap of free & used inodes

35 35 SB / bin home cbw Inode Bitmap Data Bitmap InodesData Blocks Root inode = 0 Directories are files Contains the list of entries in the directory Nameinode.0 bin1 home2 initrd.img3 Each inode can directly point to 12 blocks Can also indirectly point to blocks at 1, 2, and 3 levels of depth

36 ext2 inodes Size (bytes)NameWhat is this field for? 2modeRead/write/execute? 2uidUser ID of the file owner 4sizeSize of the file in bytes 4timeLast access time 4ctimeCreation time 4mtimeLast modification time 4dtimeDeletion time 2gidGroup ID of the file 2links_countHow many hard links point to this file? 4blocksHow many data blocks are allocated to this file? 4flagsFile or directory? Plus, other simple flags 60block15 direct and indirect pointers to data blocks 36

37 inode Block Pointers 37 Each inode is the root of an unbalanced tree of data blocks 15 total pointers 12 blocks * 4KB = 48KB 2 30 blocks * 4KB = 4TB 1024 blocks * 4KB = 4MB 1024 * 1024 blocks * 4KB = 4GB inode Single Indirect Double Indirect Triple Indirect

38 Advantages of inodes Optimized for file systems with many small files – Each inode can directly point to 48KB of data – Only one layer of indirection needed for 4MB files Faster file access – Greater meta-data locality  less random seeking – No need to traverse long, chained FAT entries Easier free space management – Bitmaps can be cached in memory for fast access – inode and data space handled independently 38

39 File Reading Example datainoderoottmpfileroottmpfile[0]file[1]file[3] open(“/tmp/file”) read read() read write read() read write read() read write BitmapsinodesData Blocks Update the last accessed time of the file Time

40 File Create and Write Example datainoderoottmpfileroottmpfile[0] open(“/tmp/file”) read write write() read write BitmapsinodesData Blocks Update the modified time of the directory Time

41 ext2 inodes, Again Size (bytes)NameWhat is this field for? 2modeRead/write/execute? 2uidUser ID of the file owner 4sizeSize of the file in bytes 4timeLast access time 4ctimeCreation time 4mtimeLast modification time 4dtimeDeletion time 2gidGroup ID of the file 2links_countHow many hard links point to this file? 4blocksHow many data blocks are allocated to this file? 4flagsFile or directory? Plus, other simple flags 60block15 direct and indirect pointers to data blocks 41

42 Hard Link Example Multiple directory entries may point to the same inode 42 home cbw amislove my_file cbw_file [amislove@ativ9 ~] ln –T../cbw/my_file cbw_file SB Inode Bitmap Data Bitmap InodesData Blocks 1.Add an entry to the “amislove” directory 2.Increase the link_count of the “my_file” inode

43 Hard Link Details Hard links give you the ability to create many aliases of the same underlying file – Can be in different directories Target file will not be marked invalid (deleted) until link_count == 0 – This is why POSIX “delete” is called unlink() Disadvantage of hard links – Inodes are only unique within a single file system – Thus, can only point to files in the same partition 43

44 Soft Links Soft links are special files that include the path to another file – Also known as symbolic links – On Windows, known as shortcuts – File may be on another partition or device 44

45 Soft Link Example 45 home cbw amislove my_file cbw_file [amislove@ativ9 ~] ln –s../cbw/my_file cbw_file SB Inode Bitmap Data Bitmap InodesData Blocks 1.Create a soft link file 2.Add it to the current directory

46 ext: The Good and the Bad The Good – ext file system (inodes) support: – All the typical file/directory features – Hard and soft links – More performant (less seeking) than FAT The Bad: poor locality – ext is optimized for a particular file size distribution – However, it is not optimized for spinning disks – inodes and associated data are far apart on the disk! 46 SB Inode Bitmap Data Bitmap InodesData Blocks

47 Partitions and Mounting Basics (FAT) inodes and Blocks (ext) Block Groups (ext2) Journaling (ext3) Extents and B-Trees (ext4) Log-based File Systems 47

48 Status Check At this point, we’ve moved from FAT to ext – inodes are imbalanced trees of data blocks – Optimized for the common case: small files Problem: ext has poor locality – inodes are far from their corresponding data – This is going to result in long seeks across the disk Problem: ext is prone to fragmentation – ext chooses the first available blocks for new data – No attempt is made to keep the blocks of a file contiguous 48

49 Fast File System (FFS) FFS developed at Berkeley in 1984 – First attempt at a disk aware file system – i.e. optimized for performance on spinning disks Observation: processes tend to access files that are in the same (or close) directories – Spatial locality Key idea: place groups of directories and their files into cylinder groups – Introduced into ext2, called block groups 49

50 50 SB Inode Bitmap Data Bitmap InodesData Blocks Block Group 1 Block Group 2 Block Group 3 Block Group 4 Block Group 5 Block Group 6 Block Groups In ext, there is a single set of key data structures – One data bitmap, one inode bitmap – One inode table, one array of data blocks In ext2, each block group contains its own key data structures

51 Allocation Policy ext2 attempts to keep related files and directories within the same block group homecbwamislove SB Block Group 1 Block Group 2 Block Group 3 Block Group 4 Block Group 5 Block Group 6

52 ext2: The Good and the Bad The good – ext2 supports: – All the features of ext… – … with even better performance (because of increased spatial locality) The bad – Large files must cross block groups – As the file system becomes more complex, the chance of file system corruption grows E.g. invalid inodes, incorrect directory entries, etc. 52

53 Partitions and Mounting Basics (FAT) inodes and Blocks (ext) Block Groups (ext2) Journaling (ext3) Extents and B-Trees (ext4) Log-based File Systems 53

54 Status Check At this point, we have a full featured file system – Directories – Fine-grained data allocation – Hard/soft links File system is optimized for spinning disks – inodes are optimized for small files – Block groups improve locality What’s next? – Consistency and reliability 54

55 Maintaining Consistency Many operations results in multiple, independent writes to the file system – Example: append a block to an existing file 1.Update the free data bitmap 2.Update the inode 3.Write the user data What happens if the computer crashes in the middle of this process? 55

56 File Append Example 56 v1 D1D1 Inode Bitmap Data Bitmap InodesData Blocks owner:christo permissions:rw size:1 pointer:4 pointer:null Update the inode v2 D2D2 Write the data owner:christo permissions:rw size:2 pointer:4 pointer:5 pointer:null Update the data bitmap These three operations can potentially be done in any order … but the system can crash at any time

57 v1 D1D1 Inode Bitmap Data Bitmap InodesData Blocks D2D2 Write the data Result: file system is consistent, but the data is lost v1 D1D1 Result: inode points to garbage data, and file system is inconsistent (data bitmap vs. inode) v2 v1 D1D1 Result: space leakage, and file system is inconsistent (data bitmap vs. inode) Update the data bitmap Update the inode

58 v1 D1D1 Inode Bitmap Data Bitmap InodesData Blocks D2D2 Result: inode points to data, but file system is inconsistent v1 D1D1 Result: file system is inconsistent, and the data is useless since it’s not associated with an inode v1 D1D1 Result: file system is consistent, but the inode points to garbage data v2 D2D2

59 The Crash Consistency Problem The disk guarantees that sector writes are atomic – No way to make multi-sector writes atomic How to ensure consistency after a crash? 1.Don’t bother to ensure consistency Accept that the file system may be inconsistent after a crash Run a program that fixes the file system during bootup File system checker (fsck) 2.Use a transaction log to make multi-writes atomic Log stores a history of all writes to the disk After a crash the log can be “replayed” to finish updates Journaling file system 59

60 Approach 1: File System Checker Key idea: fix inconsistent file systems during bootup – Unix utility called fsck (chkdsk on Windows) – Scans the entire file system multiple times, identifying and correcting inconsistencies Why during bootup? – No other file system activity can be going on – After fsck runs, bootup/mounting can continue 60

61 fsck Tasks Superblock: validate the superblock, replace it with a backup if it is corrupted Free blocks and inodes: rebuild the bitmaps by scanning all inodes Reachability: make sure all inodes are reachable from the root of the file system inodes: delete all corrupted inodes, and rebuild their link counts by walking the directory tree directories: verify the integrity of all directories … and many other minor consistency checks 61

62 fsck: the Good and the Bad Advantages of fsck – Doesn’t require the file system to do any work to ensure consistency – Makes the file system implementation simpler Disadvantages of fsck – Very complicated to implement the fsck program Many possible inconsistencies that must be identified Many difficult corner cases to consider and handle – fsck is super slow Scans the entire file system multiple times Imagine how long it would take to fsck a 40 TB RAID array 62

63 63

64 Approach 2: Journaling Problem: fsck is slow because it checks the entire file system after a crash – What if we knew where the last writes were before the crash, and just checked those? Key idea: make writes transactional by using a write-ahead log – Commonly referred to as a journal Ext3 and NTFS use journaling 64 Superblock Block Group 0 Block Group 1 … Block Group N Journal

65 Write-Ahead Log Key idea: writes to disk are first written into a log – After the log is written, the writes execute normally – In essence, the log records transactions What happens after a crash… – If the writes to the log are interrupted? The transaction is incomplete The user’s data is lost, but the file system is consistent – If the writes to the log succeed, but the normal writes are interrupted? The file system may be inconsistent, but… The log has exactly the right information to fix the problem 65

66 Data Journaling Example Assume we are appending to a file – Three writes: inode v2, data bitmap v2, data D 2 Before executing these writes, first log them 66 Journal D2D2 B v2I v2 TxB ID=1 TxE ID=1 1.Begin a new transaction with a unique ID=k 2.Write the updated meta-data block(s) 3.Write the file data block(s) 4.Write an end-of-transaction with ID=k

67 Commits and Checkpoints We say a transaction is committed after all writes to the log are complete After a transaction is committed, the OS checkpoints the update 67 Journal D2D2 B v2 I v2 TxB TxE v1 D1D1 Inode Bitmap Data Bitmap InodesData Blocks v2 D2D2 Final step: free the checkpointed transaction Committed! Checkpointed!

68 Journal Implementation Journals are typically implemented as a circular buffer – Journal is append-only OS maintains pointers to the front and back of the transactions in the buffer – As transactions are freed, the back is moved up Thus, the contents of the journal are never deleted, they are just overwritten over time 68

69 Data Journaling Timeline TxBMeta-dataDataTxEMeta-dataData Issue Complete Issue Complete 69 Time JournalFile System

70 Crash Recovery (1) What if the system crashes during logging? – If the transaction is not committed, data is lost – But, the file system remains consistent 70 Journal D2D2 B v2I v2TxB v1 D1D1 Inode Bitmap Data Bitmap InodesData Blocks

71 Crash Recovery (2) What if the system crashes during the checkpoint? – File system may be inconsistent – During reboot, transactions that are committed but not free are replayed in order – Thus, no data is lost and consistency is restored 71 Journal D2D2 B v2I v2TxBTxE v1 D1D1 Inode Bitmap Data Bitmap InodesData Blocks v2 D2D2

72 Corrupted Transactions Problem: the disk scheduler may not execute writes in-order – Transactions in the log may appear committed, when in fact they are invalid 72 Journal D2D2 B v2I v2TxBTxE Transaction looks valid, but the data is missing! During replay, garbage data is written to the file system Solution: add a checksum to TxB During recovery, reject transactions with invalid checksums Implemented on Linux in ext4

73 Journaling: The Good and the Bad Advantages of journaling – Robust, fast file system recovery No need to scan the entire journal or file system – Relatively straight forward to implement Disadvantages of journaling – Write traffic to the disk is doubled Especially the file data, which is probably large – Deletes are very hard to correctly log Example in a few slides… 73

74 Making Journaling Faster Journaling adds a lot of write overhead OSes typically batch updates to the journal – Buffer sequential writes in memory, then issue one large write to the log – Example: ext3 batches updates for 5 seconds Tradeoff between performance and persistence – Long batch interval = fewer, larger writes to the log Improved performance due to large sequential writes – But, if there is a crash, everything in the buffer will be lost 74

75 Meta-Data Journaling The most expensive part of data journaling is writing the file data twice – Meta-data is small (~1 sector), file data is large ext3 implements meta-data journaling 75 Journal B v2I v2TxBTxE v1 D1D1 Inode Bitmap Data Bitmap InodesData Blocks v2 D2D2

76 Meta-Journaling Timeline 76 TxBMeta-dataTxEMeta-dataData Issue Complete Issue Complete Issue Complete Time JournalFile System Transaction can only be committed after the meta- data and data are written

77 Crash Recovery Redux (1) What if the system crashes during logging? – If the transaction is not committed, data is lost – D 2 will eventually be overwritten – The file system remains consistent 77 Journal B v2 I v2 TxB v1 D1D1 Inode Bitmap Data Bitmap InodesData Blocks D2D2

78 Crash Recovery Redux (2) What if the system crashes during the checkpoint? – File system may be inconsistent – During reboot, transactions that are committed but not free are replayed in order – Thus, no data is lost and consistency is restored 78 Journal B v2I v2TxBTxE v1 D1D1 Inode Bitmap Data Bitmap InodesData Blocks v2 D2D2

79 Delete and Block Reuse 1.Create a directory: inode and data are written 2.Delete the directory: inode is removed 3.Create a file: inode and data are written 79 Journal dir TxB Inode Bitmap Data Bitmap InodesData Blocks f1 dir TxEdir TxBTxE dir f1 TxBTxE The block that previously held directory info is reused to hold file data

80 The Trouble With Delete What happens when the log is replayed? 80 Journal dir TxB Data Blocks TxEdir TxBTxE f1 TxBTxE file data is overwritten by directory meta-data dir file data is not in the log, thus it is lost! :(

81 Handling Delete Strategy 1: don’t reuse blocks until the delete is checkpointed and freed Strategy 2: add a revoke record to the log – ext3 used revoke records 81 Journal dir TxB ID=1 TxE Rx ID=1 dir TxB ID=2 TxEf1 TxB ID=3 TxE If the log is replayed, ignore transaction ID=1

82 Journaling Wrap-Up Today, most OSes use journaling file systems – ext3/ext4 on Linux – NTFS on Windows Provides excellent crash recovery with relatively low space and performance overhead Next-gen OSes will likely move to file systems with copy-on-write semantics – btrfs and zfs on Linux 82

83 Partitions and Mounting Basics (FAT) inodes and Blocks (ext) Block Groups (ext2) Journaling (ext3) Extents and B-Trees (ext4) Log-based File Systems 83

84 Status Check At this point: – We not only have a fast file system – But it is also resilient against corruption What’s next? – More efficiency improvements! 84

85 Revisiting inodes Recall: inodes use indirection to acquire additional blocks of pointers Problem: inodes are not efficient for large files – Example: for a 100MB file, you need 25600 block pointers (assuming 4KB blocks) This is unavoidable if the file is 100% fragmented – However, what if large groups of blocks are contiguous? 85

86 From Pointers to Extents Modern file systems try hard to minimize fragmentation – Since it results in many seeks, thus low performance Extents are better suited for contiguous files 86 inode block 1 block 2 block 3 block 4 block 5 block 6 inode block 1 length 1 block 2 length 2 block 3 length 3 Each extent includes a block pointer and a length

87 Implementing Extents ext4 and NTFS use extents ext4 inodes include 4 extents instead of block pointers – Each extent can address at most 128MB of contiguous space (assuming 4KB blocks) – If more extents are needed, a data block is allocated – Similar to a block of indirect pointers 87

88 Revisiting Directories In ext, ext2, and ext3, each directory is a file with a list of entries – Entries are not stored in sorted order – Some entries may be blank, if they have been deleted Problem: searching for files in large directories takes O(n) time – Practically, you can’t store >10K files in a directory – It takes way too long to locate and open files 88

89 From Lists to B-Trees ext4 and NTFS encode directories as B-Trees to improve lookup time to O(log N) A B-Tree is a type of balanced tree that is optimized for storage on disk – Items are stored in sorted order in blocks – Each block stores between m and 2m items Suppose items i and j are in the root of the tree – The root must have 3 children, since it has 2 items – The three child groups contain items a j 89

90 Example B-Tree ext4 uses a B-Tree variant known as a H-Tree – The H stands for hash (sometime called B+Tree) Suppose you try to open(“my_file”, “r”) 90 hash(“my_file”) = 0x0000C194 H-Tree Node H-Tree Leaf H-Tree Root 0x00AD11020xCFF1A412 H-Tree Leaf H-Tree Node 0x0000C1950x00018201 my_file  inode H-Tree Leaf 0x0000A0D10x0000C194

91 ext4: The Good and the Bad The good – ext4 (and NTFS) supports: – All of the basic file system functionality we require – Improved performance from ext3’s block groups – Additional performance gains from extents and B- Tree directory files The bad: – ext4 is an incremental improvement over ext3 – Next-gen file systems have even nicer features Copy-on-write semantics (btrfs and ZFS) 91

92 Partitions and Mounting Basics (FAT) inodes and Blocks (ext) Block Groups (ext2) Journaling (ext3) Extents and B-Trees (ext4) Log-based File Systems 92

93 Status Check At this point: – We have arrived at a modern file system like ext4 What’s next? – Go back to the drawing board and reevaluate from first-principals 93

94 Reevaluating Disk Performance How has computer hardware been evolving? – RAM has become cheaper and grown larger :) – Random access seek times have remained very slow :( This changing dynamic alters how disks are used – More data can be cached in RAM = less disk reads – Thus, writes will dominate disk I/O Can we create a file system that is optimized for sequential writes? 94

95 Log-structured File System Key idea: buffer all writes (including meta-data) in memory – Write these long segments to disk sequentially – Treat the disk as a circular buffer, i.e. don’t overwrite Advantages: – All writes are large and sequential Big question: – How do you manage meta-data and maintain structure in this kind of design? 95

96 Treating the Disk as a Log Same concept as data journaling – Data and meta-data get appended to a log – Stale data isn’t overwritten, its replaced 96 Disk Data Block 1 Data Block 2 inode 1 Data Block 5 inode 2 Data Block 1 inode 1

97 Giant Log Buffering Writes LFS buffers writes in-memory into chunks 97 Chunks get appended to the log once they are sufficiently large Memory Disk Data Block 1 Data Block 2 Data Block 3 Data Block 4 inode 1 Data Block 5 inode 2

98 How to Find inodes In a typical file system, the inodes are stored at fixed locations (relatively easy to find) How do you find inodes in the log? – Remember, there may be multiple copies of a given inode Solution: add a level of indirection – The traditional inode map can be broken into pieces – When a portion of the inode map is updated, write it to the log! 98

99 Giant Log inode map N inode Maps 99 Memory Disk Data Block 1 Data Block 2 Data Block 3 Data Block 4 inode 1 Data Block 5 inode 2 New problem: the inode map is scattered throughout the log – How do we find the most up-to-date pieces?

100 The Checkpoint Region The superblock in LFS contains pointers to all of the up-to-date inode maps – The checkpoint region is always cached in memory – Written periodically to disk, say ~30 seconds – Only part of LFS that isn’t maintained in the log 100 inode map N Disk Data Block 1 Data Block 2 Data Block 3 Data Block 4 inode 1 Data Block 5 inode 2 CR

101 How to Read a File in LFS Suppose you want to read inode 1 1.Look up inode 1 in the checkpoint region inode map containing inode 1 is in sector X 2.Read the inode map at sector X inode 1 is in sector Y 3.Read inode 1 File data is in sectors A, B, C, etc. 101 inode map N Disk Data Block 1 Data Block 2 Data Block 3 Data Block 4 inode 1 Data Block 5 inode 2 CR

102 Directories in LFS Directories are stored just like in typical file systems – Directory data stored in a file – inode points to the directory file – Directory file contains name  inode mappings 102 inode map N Disk Data Block 1 Data Block 2 Data Block 3 Data Block 4 inode 1 Dir Data 1 inode 2 CR

103 Garbage Over time, the log is going to fill up with stale data – Highly fragmented: live data mixed with stale data Periodically, the log must be garbage collected 103 Disk Data Block 1 Data Block 2 inode 1 Data Block 5 inode 2 Data Block 1 inode 1

104 Garbage Collection in LFS 104 Disk D1 i1D2i2D1i1D3 Cluster 1Cluster 2 Memory D1 i1D2i2 D1 D2i2i1 S SS S Summary block Each cluster has a summary block – Contains the block  inode mapping for each block in the cluster To check liveness, the GC reads each file with blocks in the cluster – If the current info doesn’t match the summary, blocks are stale Which blocks are stale? Pointers from other clusters are invisible

105 An Idea Whose Time Has Come LFS seems like a very strange design – Totally unlike traditional file system structures – Doesn’t map well to our ideas about directory heirarchies Initially, people did not like LFS However, today it’s features are widely used 105

106 File Systems for SSDs SSD hardware constraints – To implement wear leveling, writes must be spread across the blocks of flash – Periodically, old blocks need to be garbage collected to prevent write-amplification Does this sounds familiar? LFS is the ideal file system for SSDs! Internally, SSDs manage all files in a LFS – This is transparent to the OS and end-users – Ideal for wear-leveling and avoiding write- amplification 106

107 Copy-on-write Modern file systems incorporate ideas from LFS Copy-on-write sematics – Updated data is written to empty space on disk, rather than overwriting the original data – Helps prevent data corruption, improves sequential write performance Pioneered by LFS, now used in ZFS and btrfs – btrfs will probably be the next default file system in Linux 107

108 Versioning File Systems LFS keeps old copies of data by default Old versions of files may be useful! – Example: accidental file deletion – Example: accidentally doing open(file, ‘w’) on a file full of data Turn LFS flaw into a virtue Many modern file systems are versioned – Old copies of data are exposed to the user – The user may roll-back a file to recover old versions 108


Download ppt "CS 5600 Computer Systems Lecture 10: File Systems."

Similar presentations


Ads by Google