Never modify the only copy!
If the system fails before the post-commit phase completes, it can recover by finishing the post-commit discipline after a system failure. Recovery must be idempotent so that if the system crashes in the middle, it will recover again. Recovery must handle aborts as well as commits.
A system can achieve better performance by letting other accesses peek into the internals of the operation. A reader can get the old version from the main disk before commitment and the new version from a copy disk after commitment (but should not try during commitment). We can even give a reader the data from the source (instead of from disk). However, the reader can not commit changes to the system until a prior commitment has finished. Also, such a system can have cascading aborts (OSP Sidebar 9-3).
For disks, we can assume single-sector writes are atomic. Why? A disk head has enough capacitance to finish a write if a power failure occurs. For other devices, this may not be true. Sectors can be scrambled by a write during a power outage. One solution to this problem is to assign, for each data sector that is to have the all-or-nothing property, three physical sectors. (OSP 9.B.1) To service a request to write to a data sector, sequentially write to each of the three physical sectors. To read from a data sector, compare the contents of the first two physical sectors. If their contents are identical, return that value. Otherwise, return the contents of the third physical sector (OSP Figure 9-6).
Data state | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
---|---|---|---|---|---|---|---|
Sector S1 | old | bad | new | new | new | new | new |
Sector S2 | old | old | old | bad | new | new | new |
Sector S3 | old | old | old | old | old | bad | new |
However, this design assumes that all three physical sectors are identical before writing. A previous failure can violate this assumption. To fix this bug, check and repair the sectors (by forcing them to be identical) before writing (OSP Figure 9-7).
To write a new version of a file atomically:
When you reboot, look for commit records. If you find one, recover by finishing the post-commit discipline.
Instead of copying the whole file system, only copy parts being changed. Look at the journal for atomicity. Look at cell storage for fast reads. Look at OSP Figure 9-17. Basic logging protocol: Log the update before installing it. Run a recovery procedure after a reboot.
For an in-memory database, the journal is on disk and cell storage is in RAM (OSP 9.C.2):
For write-ahead logging, use roll-forward (redo) recovery:
For write-behind logging, use roll-back (undo) recovery:
A fault tolerant (FT) system can a survive a failure without drawing notice from users. A highly available (HA) system can survive a failure, but the system's performance may be degraded until recovery.
A measure of the length of time a storage medium remembers data.