You are expected to understand this. CS 111 Operating Systems Principles, Fall 2007
You are here: CS111: [[notes:lec13]]
 
 
 

Lecture 13 Scribe Notes

--- Matthew Karpeles 2007/11/22 13:30 --- Rogelio Vargas 2007/11/25 15:30 --- Tim Cherry 2007/11/25 16:00

File Systems III

  1. Disk Scheduling
  2. Journals
  3. Redundancy
How do we decide what cache data to write to the disk?

cache_data.jpg

  • Dallying -> Keep written cache in buffer for awhile in hopes of combining it with multiple writes, i.e.
Write Request Request Concatenation
write(1, "A") write(1, "XBC", 3)
write(1, "B")
write(1, "C")
seek(fd, SEEK_SET, 0)
write(1, "X")

This shows how a group of write requests can be combined into a single request in order to improve utilization.

A Dirty Block is a block whose in-memory version is NEWER than the copy on disk. If a disk has a dirty block then we have work to do in the future (write data back to the disk), but in what order?

Why Is Do We Need Disk Scheduling?

The two main reasons are because multiple processes can request to read and or write to a disk at a time which leads to requests being created faster than they can be serviced. And secondly because of the techniques of prefetching and batching (in order to reduce seek time in disks), reads and writes of sectors are typically performed in groups. Disk scheduling is a method used to decide the order of writing or reading disk blocks. Because of the number of requests that can exist within a system scheduling requests can have an important effect on performance. The cost of reading or writing to disk is significant and the cost is due to the sweep performed by the arm of the drive, called the seek time. The cost of or number of sweeps can be reduced by the using different disk scheduling algorithms in an effort to achieve better performance.

Disk Scheduling

The OS has a set of dirty blocks and it has to decide in what order to write these blocks. Unlike processes context switching, in writing blocks of data seek times vary in the amount of time required. In comparing scheduling of processes and disks we can make the comparison of context switch in processes to seek time in disks.

Seek Time Model

S(B1, B2) = { 1 if B2 = B1 + 1, 1000 x | B2-B1 | otherwise };

First Come First Serve (FCFS)

In a FCFS disk scheduling algorithm, we read or write blocks in the order they are requested. Using the Seek Time Model here is an example schedule:

Requested Blocks
0 10 1 11 2 12

=> Cost = 10,000 + 9,000 + 10,000 + 9,000 + 10,000

      = 48,000 units of time
  • Advantage: Can not suffer from starvation
  • Disadvantage: Performance is potentially very poor
Shortest Seek Time First (SSTF)

The basic idea is that at each step we write the block that is closest to the disk head position in terms of seek time.

Using the same Example we can can calculate the cost: => Cost = 1 + 1 + 8,000 + 1 + 1

      = 8,004 units of time
  • Advantage: Improved utilization
  • Disadvantage: Possible starvation.
    • If you have to write block 10 million but requests keep entering at 0,1,2,0,1,2... Then block 10 million will always have a greater cost.
Elevator Scheduling

It employs the same basic idea of SSTF but eliminates starvation.

elevator.jpg

The idea is that the elevator makes a pass of the entire building in a single direction. Seek first in the shortest direction meaning if 4 pushes up, then 2 pushes up and finally 3 pushes down, the order in which they are serviced is as follows. 2 gets picked up first, then 4 gets picked up and once these two are dropped off then as the elevator goes back down, 3 gets picked up.

  • This works by satisfying requests in the shortest seek time first constrained by the direction.
  • Once we run out of requests in one direction then we change directions.
  • One way elevator scheduling
    • Circle Scan (C-Scan) - This works simliar to elevator scheduling. Since it is a lot cheaper to write to disks in sequencial order, it makes more sense to seek for relevant sectors as they go under head in sequencial order. So as a disk rotates around from point A on the disk and passes sector X which later needs to be modified, it makes more sense to continue rotating the disk in the same direction and reach that sector X, as apose to completly stopping the disk once it reached point A and going in the opposite direction.

File System Invariants

  1. Every block is used for exactly 1 file system purpose
  2. All Referenced blocks are initialized
  3. No Referenced blocks are marked free
  4. All unreferenced blocks are marked free

Note : This presents a possible contradiction, since we can't write to a data block and the bitmap at the same exact time. If we were to write to the bitmap before writing to a data block then we break 4. If we write to the data block before the bitmap then we break 3. So What do we do?

We must develop a method to ensure robustness against possible write/disk failures. Then we ensure this by implementing a combination of the following:

  1. Ordering Writes (This presents problems with performance, and also violates 4).
  2. File System Checker program which scans disks, checks for invariants, and makes changes to enforce FS Invariants (Slow by can be improved upon).
  3. Journaling : write a copy of blocks, and keep track of writes using a Commit Record.

Golden Rule of Atomicity : Never modify the only copy of a large consistent object.

Commit Record : Did the entire sequence of writes/updates succeed or fail?

Write-ahead logs/ Journaling

  • Write a copy of the blocks, plus, a one-block COMMIT_RECORD.
  • There is a journal portion on the disk now in order to keep track of transactions.
  • A journal transaction is
    • Start marker (1 Block)
    • Copies of disk data blocks + their numbers ( >=Blocks)
    • We never split a high level operation across transactions. (one or more high level operations).
    • COMMIT_RECORD(1 Block)
      • If the transaction has the commit record, then all the transactions are stable
      • If no commit record, no changes are visible.
    • Recovery procedure copies blocks into main file system
    • When recovery procedure completes, erase transactions.
  • Start record -> data blocks -> commit record
    • If commit record is written, on reboot the change is seen, else, it is not visible and the disk is still consistent.
    • We cannot write the comit record until all blocks of a transaction are written.
    • When recovery is completed is clears the transactions

--- Matthew Karpeles 2007/11/22 15:29 --- Rogelio Vargas 2007/11/25 15:30 --- Tim Cherry 2007/11/25 16:00

 
notes/lec13.txt · Last modified: 2007/11/25 17:10 by rogelio.v
 
Recent changes RSS feed Driven by DokuWiki