The problem

The current contents of a given disk file are defined by data residing at many different locations in the physical machine. Some data is on the disk, some data is in ECS and some data may be in CM. In order to completely restore the contents of a disk file after a crash to the contents immediately before the crash, all of this data must be available. We made the somewhat arbitrary decision to ignore the data in CM and ECS during crash recovery. This decision was motivated by three considerations. First, it was easier to write a recovery procedure that relied solely on data stored on the disk. Second, a more complicated procedure must include a procedure depending only on the disk, in the event that data in CM and ECS proved inconsistent. Finally, we felt that in most crashes the data in CM and ECS would be unreliable, thus we must be prepared to recover from the disk alone. It is conceivable that the system could have been designed so that the data on the disk represented a ``snapshot'' of each file, taken by request of a user program. (That is, make sure the disk version of the file correctly represents the current contents.) At one time during the design we attempted to do this. However, we decided that it was wasteful of disk space. Consequently, the system took snapshots from time to time, unpredictably. Moreover, these snapshots only included data in ECS, they excluded data in CM. Thus, a snapshot might include some changes to the file made later than other changes which were not included, if the earlier changes were still in CM. In an attempt to permit a program which was using disk files to protect itself over crashes, we provided an action that forced a snapshot. At the completion of this action, the data on the disk would be a faithful representation of the file. (This was true only if all data representing the file was in ECS or on the disk, and no other program was modifying the file.)