file systems
play

File Systems CS 4410 Operating Systems [R. Agarwal, L. Alvisi, A. - PowerPoint PPT Presentation

File Systems CS 4410 Operating Systems [R. Agarwal, L. Alvisi, A. Bracy, M. George, Kurose, Ross, E. Sirer, R. Van Renesse] The abstraction stack I/O systems are accessed Application through a series of Library layered abstractions File


  1. File Systems CS 4410 Operating Systems [R. Agarwal, L. Alvisi, A. Bracy, M. George, Kurose, Ross, E. Sirer, R. Van Renesse]

  2. The abstraction stack I/O systems are accessed Application through a series of Library layered abstractions File System API File System & Performance File System API Block Cache & Performance Block Device Interface Device Device Driver Device Access Access Memory-mapped I/O, DMA, Interrupts Physical Device

  3. The Block Cache Application Library • a cache for the disk File System • caches recently read blocks File System API Block Cache & Performance • buffers recently written blocks Block Device Interface • serves as synchronization point (ensures a block is only Device Driver Device fetched once) Access Memory-mapped I/O, DMA, Interrupts • Big part of A4 Physical Device

  4. More Layers (not a 4410 focus) • allows data to be read or Application written in fixed-sized blocks Library • uniform interface to disparate File System devices File System API Block Cache • translate between OS & Performance abstractions and hw-specific Block Device Interface ignored details of I/O devices Device Driver Device in A4 Access Memory-mapped I/O, DMA, Interrupts • Control registers, bulk data Physical Device transfer, OS notifications

  5. Where shall we store our data? Process Memory? (why is this a bad idea?) 5

  6. File Systems 101 Long-term Information Storage Needs • large amounts of information • information must survive processes • need concurrent access to multiple processes Solution: the File System Abstraction • Presents applications w/ persistent , named data • Two main components: • Files • Directories 6

  7. The File • File: a named collection of data • has two parts • data – what a user or application puts in it - array of untyped bytes • metadata – information added and managed by the OS - size, owner, security info, modification time 7

  8. First things first: Name the File! 1. Files are abstracted unit of information 2. Don’t care exactly where on disk the file is ➜ Files have human readable names • file given name upon creation • use the name to access the file 8

  9. Name + Extension Naming Conventions • Some things OS dependent: Windows not case sensitive, UNIX is • Some things common: Usually ok up to 255 characters File Extensions, OS dependent: • Windows: - attaches meaning to extensions - associates applications to extensions • UNIX: - extensions not enforced by OS - Some apps might insist upon them (.c, .h, .o, .s, for C compiler) 9

  10. Directory Directory: provides names for files • a list of human readable names • a mapping from each name to a specific underlying file or directory File directory File index Storage Number Name: structure Block 871 foo.txt music 320 work 219 foo.txt 871 10

  11. Path Names Absolute: path of file from the root directory /home/ada/projects/babbage.txt Relative: path from the current working directory (current work dir stored in process’ PCB) 2 special entries in each UNIX directory: “.” current dir “..” for parent To access a file: • Go to the folder where file resides —OR— • Specify the path where the file is 11

  12. Directories OS uses path name to find directory all files Example: /home/tom/foo.txt File 2 bin 737 ˝ / ˝ usr 924 home 158 File 158 mike 682 ˝ /home ˝ ada 818 tom 830 File 830 music 320 ˝ /home/tom ˝ work 219 Directory: foo.txt 871 maps file name to attributes & location File 871 2 options: The quick ˝ /home/tom/foo.txt ˝ brown fox • directory stores attributes jumped over the • files’ attributes stored elsewhere lazy dog. 12

  13. Basic File System Operations • Create a file • Write to a file • Read from a file • Seek to somewhere in a file • Delete a file • Truncate a file 13

  14. How shall we implement this? Just map keys (file name) to values (block number on disk)? 14

  15. Challenges for File System Designers Performance: despite limitations of disks • leverage spatial locality Flexibility: need jacks-of-all-trades, diverse workloads, not just FS for X Persistence: maintain/update user data + internal data structures on persistent storage devices Reliability: must store data for long periods of time, despite OS crashes or HW malfunctions 15

  16. Implementation Basics Directories • file name ➜ file number Index structures • file number ➜ block Free space maps • find a free block; better: find a free block nearby Locality heuristics • policies enabled by above mechanisms - group directories - make writes sequential - defragment 16

  17. File System Properties Most files are small • need strong support for small files • block size can’t be too big Some files are very large • must allow large files • large file access should be reasonably efficient 17

  18. Storing Files Files can be allocated in different ways: • Contiguous allocation All bytes together, in order • Linked Structure Each block points to the next block • Indexed Structure Index block points to many other blocks Which is best? • For sequential access? Random access? • Large files? Small files? Mixed? 19

  19. Contiguous Allocation All bytes together, in order + Simple: state required per file: start block & size + Efficient: entire file can be read with one seek – Fragmentation: external is bigger problem – Usability: user needs to know size of file file1 file2 file3 file4 file5 Used in CD-ROMs, DVDs 20

  20. Linked List Allocation Each file is stored as linked list of blocks First word of each block points to next block • Rest of disk block is file data • + Space Utilization: no space lost to external fragmentation + Simple: only need to store 1 st block of each file – Performance: random access is slow – Space Utilization: overhead of pointers File A File File File File File block block block block block 0 1 2 3 4 next next next next next Physical 7 8 33 17 4 21 Block

  21. File Allocation Table (FAT) FS [late 70’s] Microsoft File Allocation Table • originally: MS-DOS, early version of Windows • today: still widely used (e.g., CD-ROMs, thumb drives, camera cards) • FAT-32, supports 2 28 blocks and files of 2 32 -1 bytes File table: • Linear map of all blocks on disk • Each file a linked list of blocks data decoupled physically data data data next next next 22 32 bit entries

  22. FAT File System FAT Data Blocks • 1 entry per block 0 0 File 9 0 1 • EOF for last block File 12 0 2 • 0 indicates free block 3 File 9 Block 3 0 4 • usually uses a simple 0 5 0 6 allocation strategy (e.g. 0 7 0 8 next-fit) 9 File 9 Block 0 10 File 9 Block 1 • directory entry maps 11 File 9 Block 2 name to FAT index 12 File 12 Block 0 0 13 0 14 Directory 0 15 EOF 16 bart.txt 9 File 12 Block 1 EOF 17 File 9 Block 4 maggie.txt 12 0 18 0 19 23 0 20

  23. FAT Directory Structure music 320 work 219 Folder: a file with 32-byte entries foo.txt 871 Each Entry: • 8 byte name + 3 byte extension (ASCII) • creation date and time • last modification date and time • first block in the file (index into FAT) • size of the file • Long and Unicode file names take up multiple entries 24

  24. How is FAT Good? + Simple: state required per file: start block only + Widely supported + No external fragmentation + block used only for data 25

  25. How is FAT Bad? • Poor locality • Many file seeks unless entire FAT in memory: Example: 1TB (2 40 bytes) disk, 4KB (2 12 ) block size, FAT has 256 million (2 28 ) entries (!) 4 bytes per entry ➜ 1GB (2 30 ) of main memory required for FS (a sizeable overhead) • Poor random access • Limited metadata • Limited access control • Limitations on volume and file size • No support for reliability techniques 26

  26. [mid 80’s] Fast File System (FFS) UNIX Fast File System Tree-based, multi-level index …but first… A4 27

  27. FFS Superblock Identifies file system’s key parameters: • type • block size • inode array location and size (or analogous structure for other FSs) • location of free list block number 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 blocks: super i-node Remaining blocks block blocks 28

  28. FFS I-Nodes Inode Array Inode • inode array File Metadata - Analogous to FAT table Direct Pointer • inode DP DP DP - Metadata DP DP DP - 12 data pointers DP DP DP - 3 indirect pointers DP Direct Pointer Indirect Pointer Dbl. Indirect Ptr. Tripl. Indirect Ptr. block number 0 1 2 3 4 5 6 7 . . . blocks: 29 superblock i-node blocks Remaining blocks

  29. FFS: Index Structures 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. 30

  30. What else is in an inode? • Type File - ordinary file File Metadata Metadata - directory - symbolic link Direct Pointer - special device DP DP • Size of the file (in #bytes) DP DP • # links to the i-node DP • Owner (user id and group id) DP DP • Protection bits DP • Times: creation, last accessed, DP DP last modified Direct Pointer Indirect Pointer Dbl. Indirect Ptr. 31 Tripl. Indirect Ptr.

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend