goals for today
play

Goals for Today Learning Objective: Inspect Linux Disk Scheduling - PowerPoint PPT Presentation

Goals for Today Learning Objective: Inspect Linux Disk Scheduling Algorithms Survey concepts in File Systems Design Announcements, etc: MP3 is now available for download on Compass! DUE APRIL 15th (15 days from now)


  1. Goals for Today • Learning Objective: • Inspect Linux Disk Scheduling Algorithms • Survey concepts in File Systems Design • Announcements, etc: • MP3 is now available for download on Compass! DUE APRIL 15th (15 days from now) • • MP2.5 (optional) available! Details on Piazza. Contact me by April 8th if you would like to participate. Reminder : Please put away devices at the start of class CS 423: Operating Systems Design 1

  2. CS 423 
 Operating System Design: File Systems in Practice Professor Adam Bates CS 423: Operating Systems Design

  3. Symbolic Links ■ Symbolic links are different than regular links (often called hard links ). Created with ln -s ■ Can be thought of as a directory entry that points to the name of another file. ■ Does not change link count for file When original deleted, symbolic link remains ■ ■ They exist because: Hard links don’t work across file systems ■ Hard links only work for regular files, not directories ■ direct Contents of file symlink direct Contents of file direct Hard link(s) Symbolic Link CS 423: Operating Systems Design 3

  4. Linked Files File header File header points to 1st ■ block on disk Each block points to next ■ Pros ■ Can grow files dynamically ■ Free list is similar to a file ■ . . . Cons ■ random access: horrible ■ unreliable: losing a block ■ means losing the rest null CS 423: Operating Systems Design 4

  5. Linked Allocation CS 423: Operating Systems Design 5

  6. Indexed File Allocation Link full index blocks together using last entry. CS 423: Operating Systems Design 6

  7. Multilevel Indexed Files Multiple levels of index blocks CS 423: Operating Systems Design 7

  8. File Systems In Practice FAT Berkeley FFS NTFS (Unix FS) Index Linked list Tree Tree structure (fixed, assym) (dynamic) granularity block block extent free space FAT array Bitmap Bitmap allocaCon (fixed (file) locaCon) Locality defragmentaCon Block groups Extents + reserve Best fit space defrag CS 423: Operating Systems Design 8

  9. MS File Allocation Table (FAT) ■ Linked list index structure ■ Simple, easy to implement ■ Still widely used (e.g., thumb drives) ■ File table: ■ Linear map of all blocks on disk ■ Each file a linked list of blocks CS 423: Operating Systems Design 9

  10. MS File Allocation Table (FAT) MFT Data Blocks 0 1 2 3 fj le 9 block 3 4 5 6 7 8 fj le 9 block 0 9 fj le 9 block 1 10 11 fj le 9 block 2 12 fj le 12 block 0 13 14 15 16 fj le 12 block 1 17 18 fj le 9 block 4 19 20 CS 423: Operating Systems Design 10

  11. MS File Allocation Table (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 ■ Fragmentation ■ File blocks for a given file may be scattered ■ Files in the same directory may be scattered ■ Problem becomes worse as disk fills CS 423: Operating Systems Design 11

  12. Berkeley FFS / UNIX FS ■ “Fast File System” ■ inode table ■ Analogous to FAT table ■ inode ■ Metadata ■ File owner, access permissions, access times, … ■ Set of 12 data pointers ■ With 4KB blocks => max size of 48KB files ■ Indirect block pointers ■ pointer to disk block of data pointers ■ w/ indirect blocks, we can point to 1K data blocks => 4MB (+48KB) ■ … but why stop there?? CS 423: Operating Systems Design 12

  13. Berkeley FFS / UNIX FS ■ Doubly indirect block pointer ■ w/ doubly indirect blocks, we can point to 1K indirect blocks ■ => 4GB (+ 4MB + 48KB) ■ Triply indirect block pointer ■ w/ triply indirect blocks, we can point to 1K doubly indirect blocks ■ 4TB (+ 4GB + 4MB + 48KB) CS 423: Operating Systems Design 13

  14. Berkeley FFS / UNIX FS Open file description inode Parent File descriptor Mode File position table R/W Link Count Pointer to inode UID File position GID R/W Child Pointer to inode File File size descri Times ptor Address of table first 10 disk blocks Single Indirect Double Indirect Unrelated process Triple Indirect File descriptor table CS 423: Operating Systems Design 14 � 14

  15. Berkeley FFS / UNIX FS Alternate figure, same basic idea Inode Array Triple Double Indirect Indirect Indirect Data Inode Blocks Blocks Blocks Blocks File Metadata Direct Pointer DP DP DP DP DP DP DP DP DP DP Direct Pointer Indirect Pointer Dbl. Indirect Ptr. Tripl. Indirect Ptr. CS 423: Operating Systems Design 15

  16. Berkeley FFS Asym. Trees ■ Indirection has a cost. Only use if needed! ■ Small files: shallow tree ■ Efficient storage for small files ■ Large files: deep tree ■ Efficient lookup for random access in large files ■ Sparse files: only fill pointers if needed CS 423: Operating Systems Design 16

  17. Berkeley FFS Locality ■ How does FFS provide locality? ■ Block group allocation ■ Block group is a set of nearby cylinders ■ Files in same directory located in same group ■ Subdirectories located in different block groups ■ inode table spread throughout disk ■ inodes, bitmap near file blocks ■ First fit allocation ■ Property: Small files may be a little fragmented, but large files will be contiguous CS 423: Operating Systems Design 17

  18. Berkeley FFS Locality Block Group 0 Block Group 1 s e d Block Group 2 o n I p / a / d n p a a , c c m / / b D t , i / q B a / d t d e F a n / c r a B e a s l e p , e o d i S S c r / o k p e , t a s e a c / c f r e o F r s e i s r e d B e fj i n r i d l i o t e s m D e o t s a l fj t c n a r i a B o n l f e o s c k I p r d i d i r e n c t i o s r i e e s l / fj b , / a r / g , / z o I n f o s d k e c s o l B p a a t m a D t i B e c a p S e e r F CS 423: Operating Systems Design 18

  19. Berkeley FFS Locality ■ How does FFS provide locality? ■ Block group allocation ■ Block group is a set of nearby cylinders ■ Files in same directory located in same group ■ Subdirectories located in different block groups ■ inode table spread throughout disk ■ inodes, bitmap near file blocks ■ First fit allocation ■ Property: Small files may be a little fragmented, but large files will be contiguous CS 423: Operating Systems Design 19

  20. Berkeley FFS Locality “First Fit” Block Allocation: In-Use Free Block Block Start of ... Block Group CS 423: Operating Systems Design 20

  21. Berkeley FFS Locality “First Fit” Block Allocation: Write Two Block File Start of ... Block Group CS 423: Operating Systems Design 21

  22. Berkeley FFS Locality “First Fit” Block Allocation: Write Large File Start of ... Block Group CS 423: Operating Systems Design 22

  23. Berkeley FFS / UNIX FS ■ Pros ■ Efficient storage for both small and large files ■ Locality for both small and large files ■ Locality for metadata and data ■ Cons ■ Inefficient for tiny files (a 1 byte file requires both an inode and a data block) ■ Inefficient encoding when file is mostly contiguous on disk (no equivalent to superpages) ■ Need to reserve 10-20% of free space to prevent fragmentation CS 423: Operating Systems Design 23

  24. NTFS ■ “New Technology File System” for Windows NT Released in ’93 ■ Incidentally, a big step forward for security in commodity OS’ ■ ■ Master File Table ■ Flexible 1KB storage for metadata and data ■ Extents ■ Block pointers cover runs of blocks ■ Similar approach in linux (ext4) ■ File create can provide hint as to size of file ■ Journalling for reliability CS 423: Operating Systems Design 24

  25. NTFS: Small File Tiny file? Store in MFT record! Master File Table MFT Record (small fj le) Std. Info. File Name Data (resident) (free) CS 423: Operating Systems Design 25

  26. NTFS: ‘Normal’ File Normal-sized file? store pointers to data extents! MFT Start Data Extent Length MFT Record Std. Info. File Name Data (nonresident) (free) Start Data Extent Length CS 423: Operating Systems Design 26

  27. NTFS: Indirect Blocks Bigger file? Store pointer to additional MFT records! MFT MFT Record (part 1) Std. Info. Attr.list File Name Data (nonresident) Data Extent Data Extent MFT Record (part 2) Std. Info. Data (nonresident) (free) Data Extent Data Extent Data Extent CS 423: Operating Systems Design 27

  28. NTFS ■ Problems? ■ This looks like indexed file allocation (plus extents) ■ Linked MTR records may lack locality on disk! CS 423: Operating Systems Design 28

  29. NTFS Defragmentation still required… MFT MFT MFT Record MFT Record (small file) (huge/badly-fragmented file) Std. Info. Attr.list (nonresident) Std. Info. Data (resident) MFT Record Extent with part of attribute list (normal file) Std. Info. Data (nonresident) Data (nonresident) MFT Record Data (nonresident) (big/fragmented file) Std. Info. Attr.list Data (nonresident) Data (nonresident) Data (nonresident) Extent with part of attribute list Data (nonresident) Data (nonresident) Data (nonresident) Data (nonresident) CS 423: Operating Systems Design 29

Recommend


More recommend