The layout of the stable storage

The stable storage is divided into two halves, the first half containing the current version of a page and the second half containing copies of changed pages. This division of the stable storage has several advantages. Firstly, the copy of a page in the first half of the store is held at the same relative position in the second half of the store. Thus, it is not necessary to explicitly record the location of a page's copy. A second advantage is that a single bit is sufficient to record whether or not a page has been copied. The division also allows the current version of every page in the stable storage to be changed between checkpoints. A disadvantage of the division of the stable storage is that only half the store is available to hold useful data. Furthermore, if checkpoints are relatively frequent then only a few of the pages in the second half of the store will be in use at any one time. Hence, the division of the stable storage may waste a significant fraction of the available storage. This disadvantage was disregarded in the first implementation of the stable storage since the resulting mechanism is both simple and efficient.

The first half of the stable storage is divided into three sections, a bitmap that records any copied pages, a pair of root pages[atk83b] and that part of the stable storage that is made available to the heap of persistent objects, as shown Figure 6.7.

Root Root Bitmap to Record Shadow Paged Page 1 Page 2 Copied Pages Stable Storage

Figure 6.7. The first half of the non-volatile store.

When a page in the first half of the stable store is to be modified, a copy of the page is written to the second half of the store. The relative position of the copied page in the second half of the store is the same as the relative position of the original page in the first half of the store. The appropriate bit in the bitmap is then set to record the fact that a copy has been made. When the page is subsequently modified, a check of the bitmap will prevent further copies being made.

In addition to preventing multiple copies, the bitmap is also used to restore the stable store to a self-consistent state. This can be achieved by scanning the bitmap and replacing any modified pages by their copies. However, this is only possible if the bitmap is up to date. To ensure that the bitmap is correct, it must be updated and written to non-volatile storage before a modified page is written but after that page has been copied. Thus, if the bitmap indicates that a page has been copied there will be a corresponding copy in the second half of the stable store. This requires a checkpoint mechanism to be applied to the bitmap to prevent it being corrupted by a failure while it is being written.

6.4.3 The root pages

The additional checkpoint mechanism is provided by a root page, two copies of which are held at the start of the stable storage. When the current value of the page is written to non-volatile storage, the older of the two copies is overwritten. To allow the copies to be differentiated, the root page has a date stamp value at either end, as shown in Figure 6.8. The copied root page with the higher time stamp is the most recent.

Date _{Non Volatile} Sizes of Store

Bitmap to Record Date

Stamp Copied Pages Stamp

Figure 6.8. The layout of a root page.

The root page records the dimensions of the non-volatile storage such as its length in blocks, its half length and the number of pages that are allocated to the bitmap. The root page also contains a root bitmap that has a bit for every page holding the main bitmap. The root bitmap is used in the same way as the main bitmap. That is, before a page in the main bitmap is written it is first copied. Once the copy has been successfully written the page's bit in the root bitmap is set. The root page is then written followed by the modified page in the main bitmap. The final use made of the root bitmap is to checkpoint the main bitmap. That is, the modified state of the main bitmap must be preserved in case it is required to restore the stable store. This is achieved by clearing the root bitmap and then writing the root page to non-volatile storage.

As an optimisation, the main bitmap can be discarded if the root bitmap is large enough to contain a bit for every page in the first half of the stable store. When this optimisation is used, the checkpoint mechanism applied to the main bitmap can be adapted for use by the entire stable store. The only significant change to the mechanism is that the root bitmap is not cleared until the entire stable store has been checkpointed. Thus, for small stable stores only one level of checkpoint mechanism is required.

The root pages' date stamps are used to detect corruption. The interface to the non-volatile store guarantees that a block is written in a predefined order and that a write only completes if successful. That is, if a root page is successfully written to non-volatile storage then the date stamp values at its start and finish are the same.

133

When a write causes corruption, the write fails and the non-volatile store causes the architecture to halt, as described in Section 6.5. Hence, the stable store can normally operate under the assumption that no corruption will occur. However, it must check for corruption when the stable store is started since the store may have stopped as the result of a failure. Any corruption can be detected by inspecting the date stamps in the two copies of the root page. The copy with the highest date stamp contains the most recent version of the root page. However, if that page's date stamps are not the same then it was corrupted and the other copy is used. Provided that the non-volatile store is not subject to a catastrophic failure, the other copy is free from corruption.

It is only necessary to check the root pages for corruption for the following reasons. A

failure in the normal operation of the stable storage may corrupt at most a single page. | Consequently, the corruption of a page's copy can be ignored since the bitmap entry for the

page would not have been recorded when the failure stopped the stable store. Similarly, the corruption of a modified version of a page can be ignored since the main bitmap will contain a reference to the page's copy. Hence, the restoration of the stable store would automatically overwrite the corrupt page with its copy. Finally, the corruption of the bitmap itself can be ignored since it will be restored by the checkpoint mechanism supported by the root pages. 6.4.4 Checkpointing the stable store

The self-consistent state recorded by the stable store can be altered using the checkpoint procedure provided by its interface. A checkpoint is performed in three steps:

a) writing every modified page to non-volatile store, b) eliminating the previous self-consistent state, and c) clearing the root bitmap.