Chapter 11 Slides

446 views
392 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
446
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Chapter 11 Slides

  1. 1. Operating Systems Chapter 11 File-Systems Implementation
  2. 2. File System Implementation <ul><li>File System Implementation </li></ul><ul><ul><li>how are those services actually implemented? </li></ul></ul><ul><ul><li>how is the disk (other I/O devices covered later) mapped for efficient storage? </li></ul></ul>
  3. 3. File System Implementation <ul><li>File System Implementation </li></ul><ul><ul><li>typical issues include: </li></ul></ul><ul><ul><ul><li>file control block (FCB) </li></ul></ul></ul><ul><ul><ul><li>disk sector – to – file allocation </li></ul></ul></ul><ul><ul><ul><li>free space management </li></ul></ul></ul><ul><ul><ul><li>performance, logging, and recovery </li></ul></ul></ul>
  4. 4. File System Implementation <ul><li>Recall the layered approach: </li></ul><ul><ul><li>device drivers at I/O layer actually talk to the hardware </li></ul></ul><ul><ul><li>basic file system handles operations on blocks of data </li></ul></ul><ul><ul><li>file organization level deals with file pointers and logical blocks of data </li></ul></ul><ul><ul><li>logical file system handles metadata of file, directories and file names, via logical operations </li></ul></ul>Copyright Martin L. Barrett 2007
  5. 5. File System Implementation <ul><li>Recall the File Control Block </li></ul><ul><ul><li>contains data structure to handle disk sector allocation; stored on disk </li></ul></ul><ul><li>In-memory structures: </li></ul><ul><ul><li>directory structure: copy of directory information </li></ul></ul><ul><ul><li>open file table (OFT): file descriptor information, some copied in from FCB </li></ul></ul><ul><ul><ul><li>per process OFT: index into system table </li></ul></ul></ul><ul><ul><ul><li>system OFT: file descriptors </li></ul></ul></ul>Copyright Martin L. Barrett 2007
  6. 6. File System Implementation <ul><li>Boot block </li></ul><ul><ul><li>information about the kernel’s location on disk </li></ul></ul><ul><li>Superblock </li></ul><ul><ul><li>information about a disk partition (number of blocks, free space info, FCB pointers) </li></ul></ul>Copyright Martin L. Barrett 2007
  7. 7. File System Implementation <ul><li>Partition </li></ul><ul><ul><li>maps cylinders on disks to logical groups </li></ul></ul><ul><ul><li>in DOS/Windows, think c: drive, d: drive; in Unix, think root partition, usr partition </li></ul></ul><ul><li>Virtual file system </li></ul><ul><ul><li>virtualization layer that allows multiple different file systems underneath, same operations by file system interface above </li></ul></ul>Copyright Martin L. Barrett 2007
  8. 8. File System Implementation <ul><li>Disk sector allocation methods </li></ul><ul><ul><li>recall that the disk is multiple platters of concentric circles of sectors, but the more efficient way to organize it is cylinders of tracks of sectors – cylinders first due to seek latency problem of moving the disk head </li></ul></ul><ul><ul><li>so: one linear collection of sectors, numbered from 0 to MAX </li></ul></ul><ul><ul><li>allocate, if possible, runs of sectors to minimize both seek latency and rotation latency </li></ul></ul>Copyright Martin L. Barrett 2007
  9. 9. File System Implementation <ul><li>Contiguous allocation </li></ul><ul><ul><li>like a memory segment: base and bounds are stored in FCB </li></ul></ul><ul><ul><li>all sectors are allocated at once </li></ul></ul><ul><ul><li>leads to external fragmentation as files are allocated and deallocated: small runs of sectors may not be usable </li></ul></ul><ul><ul><li>cannot expand a file without moving it to a new location </li></ul></ul>Copyright Martin L. Barrett 2007
  10. 10. File System Implementation <ul><li>Contiguous allocation, cont. </li></ul><ul><ul><li>variation: since one <base, bounds> isn’t enough, keep several – called extents </li></ul></ul><ul><ul><li>but with a finite number of extents, you’ve just delayed the problem – e.g., what if a file expands by one sector at a time – no matter how many extents you have, they’ll get used up </li></ul></ul>Copyright Martin L. Barrett 2007
  11. 11. File System Implementation <ul><li>Linked allocation </li></ul><ul><ul><li>use some linked list implementation, store head pointer in FCB </li></ul></ul><ul><ul><li>links can be stored in sectors, decreasing the amount of data that can be stored </li></ul></ul><ul><ul><li>links can be stored externally – the FAT variation: table (stored somewhere on disk) is like a big vector; each entry stores either NULL or a sector number (the “next” pointer) </li></ul></ul><ul><ul><li>mirror the FAT for reliability </li></ul></ul>Copyright Martin L. Barrett 2007
  12. 12. File System Implementation <ul><li>Linked allocation, cont. </li></ul><ul><ul><li>not guaranteed of runs of consecutive sectors </li></ul></ul><ul><ul><li>no external fragmentation </li></ul></ul><ul><ul><li>cluster: group of contiguous sectors, used to increase the capacity of FAT – points to next cluster (e.g, group of four consecutive sectors) </li></ul></ul><ul><ul><li>FAT copied to memory for performance => must keep it consistent with disk copies </li></ul></ul>Copyright Martin L. Barrett 2007
  13. 13. File System Implementation <ul><li>Indexed allocation </li></ul><ul><ul><li>allocates a sector for address of sectors owned by a file </li></ul></ul><ul><ul><li>when sector fills up with addresses, allocate another one and link it to previous one </li></ul></ul>Copyright Martin L. Barrett 2007
  14. 14. File System Implementation <ul><li>Indexed allocation, cont. </li></ul><ul><ul><li>Unix inode method (inode == FCB) </li></ul></ul><ul><ul><ul><li>to increase efficiency, FCB stores sector numbers of first 10 blocks allocated to the is file </li></ul></ul></ul><ul><ul><ul><li>11 th address is first indirect block: points to a sector filled with addresses </li></ul></ul></ul><ul><ul><ul><li>12 th address is second indirect block: points to a sector filled with addresses of first indirect block addresses </li></ul></ul></ul><ul><ul><ul><li>13 th address is third indirect block: points to a sector filled with addresses of second indirect block addresses </li></ul></ul></ul>Copyright Martin L. Barrett 2007
  15. 15. File System Implementation <ul><li>Indexed allocation, cont. </li></ul><ul><ul><li>Unix inodes </li></ul></ul><ul><ul><ul><li>example: suppose a sector can store 8 addresses. Then any file with 1 <= file size <= 10 sectors only uses the direct addresses in the FCB. Any file with 11 <= size <= 18 uses the direct addresses, plus one additional overhead block containing the sector numbers of the file’s blocks #11 – 18. Any file with 18 <= size <= 82 has first 18 stored as above, then allocates another overhead block to store eight addresses of that many more first indirect blocks, each storing 8 more addresses, so 8*8 = 64 ,for a total of 10 direct + 8 indirect + 64 2 nd indirect = 82 </li></ul></ul></ul>Copyright Martin L. Barrett 2007
  16. 16. File System Implementation <ul><li>Free space management </li></ul><ul><ul><li>easiest: bit map of free/used sectors on disk </li></ul></ul><ul><ul><li>linked list: links the free sectors, preferably in sector number order (for contiguous allocation) </li></ul></ul><ul><ul><li>hybrid: group contiguous blocks together to decrease the overhead of the list, e.g base and bounds pairs </li></ul></ul>Copyright Martin L. Barrett 2007
  17. 17. File System Implementation <ul><li>Performance issues </li></ul><ul><ul><li>buffering: for recently read or written sectors, either per process or global => synchronization with actual sector is a big issue, as is managing the buffer pool </li></ul></ul><ul><ul><li>read-ahead: similar to paging, reading several sectors on request for one </li></ul></ul><ul><ul><li>pre-allocation: allocating a run of sectors on file creation, even if not (yet) requested </li></ul></ul>Copyright Martin L. Barrett 2007
  18. 18. File System Implementation <ul><li>Consistency checking </li></ul><ul><ul><li>making sure whatever data structures being used give accurate mapping of file structure and disk </li></ul></ul><ul><li>Backup to more archival storage for recovery </li></ul><ul><ul><li>full backup is expensive, so only do it every so often </li></ul></ul><ul><ul><li>incrementals: daily, back up on those files changed since last backup or incremental – in fact, can store just data that changed (see diff ) </li></ul></ul>Copyright Martin L. Barrett 2007
  19. 19. File System Implementation <ul><li>Logging </li></ul><ul><ul><li>for consistent recovery after a crash, keep track of </li></ul></ul><ul><ul><ul><li>what data was changed </li></ul></ul></ul><ul><ul><ul><li>old, new versions of data (database terminology is “undo, redo” data) </li></ul></ul></ul><ul><ul><ul><li>take snapshots (backups while system is still processing – if shutting down the system is not feasible) periodically </li></ul></ul></ul><ul><ul><li>also called journaling file systems </li></ul></ul>Copyright Martin L. Barrett 2007

×