Outline

• Disk Scheduling and Failures
• RAID Levels
• In-Class Exercise
• Representing Records

Disk Scheduling

• We have been discussing some of the properties of hard disks with respect to retrieving data.
• A simple but effective way to schedule a large number of disk requests is to use the elevator algorithm.
• Basically, the head roughly moves from the inner cylinder to the outer cylinder and then back down to the inner cylinder, etc.
• As it passes a cylinder the head notices whether there has been a request for blocks on that cylinder. If so, it reads or writes those blocks.
• Once done a cylinder, the head is moved to the next cylinder in the direction it was traveling
• If there were no further requests in that direction, the direction of moving inward or outward is reversed.
• The book gives an example showing this is about 2 to 3 times more efficient then doing things first come first serve

Prefetching (aka double buffering)

• In some applications one can predict the order in which blocks will be requested from disk.
• If so, one can load them in to memory before they are needed.
• This can make it easier to schedule the disk.

Disk Failures

Let's now consider why disks drives might not work (before considering how to deal with disk failures).

• Intermittent failures - we try to do a read or write but are unsuccessful. After repeated tries though we succeed.
• Media decay - some bits on a sector become permanently corrupted and unreadable.
• Write Failures - we write some data but fail. Worse still, the old data is also gone.
• Disk crash -- entire disk is toasted. That is, suddenly the disk stops working and is permanently unreadable.

Intermittent Failures

• We now discuss each of these failures in more detail as well as how to mitigate against them.
• Disk sectors are usually stored with some extra bits that enable us to tell if the sector's content is correct or not on a read or a write.
• We model a disk read as returning a pair `(w,s)` where `w` is the data and `s` is the status as to whether the read was okay.
• In an intermittent failure, we may get several bad `s's` before a good one.
• Usually, we have some max tries (say 100) before we permanently fail.
• For write requests, after the write, we can do a read to see if the `s` is correct, and hence, if the write was successful.
• This read will typically take an additional disk revolution.
• If the write was not successful, we can repeat it.

Checksums

• What should we use for `s`?
  • A common thing to do is to take the parity of the bits in the sector for `s`. That is, `s` is 1 if the number of `1` bits in the sector is odd and `0` otherwise.
  • For example, if `w=0101100` then `s=1`. If `w=1111000` then `s=0`.

Stable Storage

• We want a policy in effect to be sure that, when we write to disk, we will get a sector which is correctly written, or that any data that was in the sector before the write can be safely recovered.
• This policy is called stable storage.

Implementing Stable Storage

• We pair sectors and each pair represents one-sector contents `X`.
• Call the two copies the left and right copies and denote them `X_L` and `X_R`.
• To write:
  • Write `X` into `X_L`. Check that `s` is good. If not repeat the write. If fail repeatedly, assume `X_L` corrupted and replace it with a different sector. Repeat this process for `X_R`.
• To read:
  • Try to read `X` from `X_L`. Check if `s` is good. If yes, then that is `X`, if not repeat. If fail repeatedly try to get the value from `X_R`.
• Above scheme works well for media and write failures.

Failure Model for Disks

• We now want to consider RAID (redundant arrays of independent disks) schemes that work well for disk crashes.
• The average time till a disk crash is called the mean time to failure (MTTF). For modern disk this is about 10 years.
• We model this by assuming roughly 10% of the disks fail in a given year.
• We want to use multiple disks to make the mean time to data loss to be a much bigger number than the MTTF.

Mirroring as a Redundancy Technique

• Suppose you have two disks with the same data.
• One is called the data disk and the other is the redundant disk.
• If a disk fails we replace it with a new disk and copy the data from the other disk that is still okay.
• What is the chance the second disk could fail during the replacement process?
  • If replacement takes 3 hours = `1/8` of a day = `1/2920` of a year, then the odds are `1/10 times 1/2920` or one in `29200` failures. The odds that one of the two disks fails in a given year is `2/10 = 1/5`. So MTTF for 2 disk is 5 years. So the mean time to data loss is `5 times 29200 = 146,000` years.
• Raid level 1 is to use mirroring.
• Raid level 0 is to use striping as described last day.
• Raid 2 and Raid 3 are rarely used. They combine either bit or byte level striping with either a Hamming code or parity bit for error detection.

In-Class Exercise

For large disks (full 16TB hard drive) with many files, it can take two days to do a complete copy of the redundant disk.

In this scenario, what would be the mean time to data loss?

Please post your solution to the Feb 1 In-Class Exercise.

Parity Blocks

• Mirroring is somewhat wasteful.
• RAID level 4 scheme assumes we have `n` data disks and one parity disk.
• The `i`th block of the parity disks consists of the parities of the data stored in the `i`th block of the other disks
• For example, if disk 1 block `i` had `1010` and disk2 block `i` had `1101` then a parity disk would have `0111`.
• To read in this set-up we don't bother with the parity disk.
• To write need to read old block and parity block. Then write new block and recalculate the parity.

RAID 4 and Failures

• If the parity disk crashes, we just replace it.
• If one disk fails then we can replace that disk and compute the value for each of its block based on the other disks and the parity blocks. For example, if

  Disk1blk1: 1001
  Disk2blk1: 1111
  Disk3blk1: ???? 
  ParityBlk1:0010
  

  Then Disk3blk1 must be:0100

RAID 5

• RAID 4 has a bottleneck whenever we need to do writes because we must also update the parity disk.
• Notice the rule of recovery for a parity disk is the same as for any other disk in RAID level 4.
• In RAID level 5 to reduce the bottleneck problem we change which disk is the parity disk depending on the block number.
• For instance, if have `n` disks then disk `j` is used as the parity disk for block `i` if `i mod n = j`.

RAID 6

• RAID 4 and 5 allow one to recover from single disk crashes.
• RAID 6 allows one to recover from multiple disk crashes.
• The idea is to divide the disks into some data disks and some redundant disks.
• We use the redundant disks to fill in the rest of a Hamming code word based on the data for that bit position in that block of the data disks.
• Such Hamming codes are error correcting and can correct for more than one disk errors.

Representing Data in Secondary Storage

How do we store relations and objects to disk?

• Attributes are stored as fixed or variable length sequences of bytes called fields.
• Fields in turn are organized into records which correspond to tuples or objects.
• Records need to be stored into disk blocks
• Finally, all the blocks used to store a relation or object are stored as a file.
• This might have additional structures associated with it such as indices.

Example

Consider trying to implement a record format for the table created by the following SQL statement:

CREATE TABLE MovieStar(
   name CHAR(30) PRIMARY KEY, 
   address VARCHAR(255),
   gender CHAR(1),
   birthdate DATE
);

• Our format needs to say:
  • How to convert CHAR, VARCHAR, etc to fields.
  • How to put the whole tuple into a record and then blocks, files, etc.
  • How to handle different sized records.
• We should also consider what happens when fields change in size

Representing Data Elements I

We now discuss how to represent various kinds of data elements:

• Fixed length strings - i.e., CHAR(n) fields for some fixed `n`.
  • To store these we just use an array of size n.
  • If a value has fewer than `n` bytes we use a special pad character.
  • For example, if we have type CHAR(5), a possible value cat might be stored as: cat**

Representing Data Elements II

• Variable-Length Character Strings - Suppose we had an attribute of type VARCHAR(n). Here `n` must be less than `255`. We could represent this in several different ways:
  • Length plus content. Allocate `n+1` bytes. Use the first byte for the length and the remaining bytes for the content. If leftover bytes ignore.
  • Null-terminated string. Allocate `n+1` bytes. Write string followed by a \0. Anything after the \0 is ignored.

Representing Data Elements III

• Date and Time - These are usually stored as a fixed length character string following some format. For example, might use format YYYY-MM-DD and have a value like "2005-02-07". Similarly, a time might have a format like HH:MM:SS.FF (SQL2) and have a value like "23:05:02.35". The .35 is the fraction of a second.