Advanced Operating Systems: Lecture 33 - Mr. Farhan Zaidi

Advanced Operating Systems - Lecture 33: Disk interaction. This lecture will cover the following: physical disk structure; disk interaction; current disks provide a higher-level interface (SCSI); disk scheduling; BSD 4.4 fast file system (FFS); FFS allocation policies;...

CS703 ­ Advanced  Operating Systems By Mr Farhan Zaidi Lecture No.  33 Disk Interaction  Specifying disk requests requires a lot of info:   Cylinder #, surface #, track #, sector #, transfer size, Current disks provide a higher-level interface (SCSI)  The disk exports its data as a logical array of blocks [0 … N]  Disk maps logical blocks to cylinder/ surface/ track/ sector Some useful facts  Disk reads/writes in terms of sectors, not bytes  read/write single sector or adjacent groups  How to write a single byte? “Read-modify-write”  read in sector containing the byte  modify that byte  write entire sector back to disk  key: if cached, don’t need to read in Sector = unit of atomicity  sector write done completely, even if crash in middle  (disk saves up enough momentum to complete)  larger atomic units have to be synthesized by OS  Disk Scheduling  Because seeks are so expensive (milliseconds!), the OS tries to schedule disk requests that are queued waiting for the disk  FCFS (do nothing)    SSTF (shortest seek time first)    Minimize arm movement (seek time), maximize request rate Favors middle blocks SCAN (elevator)   Reasonable when load is low Long waiting times for long request queues Service requests in one direction until done, then reverse C-SCAN  Like SCAN, but only go in one direction (typewriter) Some useful trends  Disk bandwidth and cost/bit improving exponentially   Seek time and rotational delay improving *very* slowly   similar to CPU speed, memory size, etc why? require moving physical object (disk arm) Some implications:    disk accesses a huge system bottleneck & getting worse bandwidth increase lets system (pre-)fetch large chunks for about the same cost as small chunk  Result? Can improve performance if you can read lots of related stuff  How to get related stuff? Cluster together on disk Memory size increasing faster than typical workload size  More and more of workload fits in file cache  disk traffic changes: mostly writes and new data BSD 4.4 Fast File system (FFS)      Used a minimum of 4096 size disk block Records the block size in superblock Multiple file systems with different block sizes can coreside Improves performance in several ways Superblock is replicated to provide fault tolerance FFS Allocation Policies Allocate file inodes close to their containing directories For mkdir, select a cylinder group with a more-than-average number of free inodes For creat, place inode in the same group as the parent   Concentrate related file data blocks in cylinder groups Most files are read and written sequentially Place initial blocks of a file in the same group as its inode    How should we handle directory blocks? Place adjacent logical blocks in the same cylinder group    Logical block n+1 goes in the same group as block n Switch to a different group for each indirect block Representing Small Files  Internal fragmentation in the file system blocks can waste significant space for small files  FFS solution: optimize small files for space efficiency  Subdivide blocks into 2/ 4/ fragments (or just frags) Clustering in FFS  Clustering improves bandwidth utilization for large files read and written sequentially  FFS can allocate contiguous runs of blocks “most of the time” on disks with sufficient free space FFS consistency and recovery    Reconstructs free list and reference counts on reboot Enforces two invariants: directory names always reference valid inodes  no block claimed by more than one inode Does this with three ordering rules:  write newly allocated inode to disk before name entered in directory  remove directory name before inode deallocated  write deallocated inode to disk before its blocks are placed on free list File creation and deletion take synchronous writes Why does FFS need third rule? Inode recovery     FFS: inode recovery  Files can be lost if directory destroyed or crash happens before link can be set New twist: FFS can find lost inodes Facts:  FFS pre-allocates inodes in known locations on disk  Free inodes are initialized to all 0s So?  Fact lets FFS find all inodes (whether or not there are any pointers to them)  Fact tells FFS that any inode with non-zero contents is (probably) still in use  fsck places unreferenced inodes with non-zero contents in the lost+found directory    .. .Lecture? ?No.  33 Disk Interaction  Specifying disk requests requires a lot of info:   Cylinder #, surface #, track #, sector #, transfer size, Current disks provide a higher-level... sectors, not bytes  read/write single sector or adjacent groups  How to write a single byte? “Read-modify-write”  read in sector containing the byte  modify that byte  write entire sector back to... file inodes close to their containing directories For mkdir, select a cylinder group with a more-than-average number of free inodes For creat, place inode in the same group as the parent   Concentrate