2.5. Updates to the ﬁle system Every working day hundreds of ﬁles are created, modiﬁed, and removed. Every time ale is modi- ﬁed, the operating system performs a series of ﬁle system updates. These updates, when written on disk, yield a consistent ﬁle system. The ﬁle system stages all modiﬁcations of critical information modiﬁcation can either be completed or cleanly backed out after a crash. Knowing the information that is ﬁrst written to the ﬁle system, deterministic procedures can be developed to repair a corrupted ﬁle system. To understand this process, the order that the update requests were being honored must ﬁrst be understood. When a user program does an operation to change the ﬁle system, such as a write, the data to be written is copied into an internal in-core buffer in the kernel. Normally, the disk update is handled asynchronously the user process is allowed to proceed even though the data has not yet been written to the disk. The data, along with the inode information reﬂecting the change, is eventually written out to disk. The real disk write may not happen until long after the write system call has returned. Thus at any given time, the ﬁle system, as it resides on the disk, lags the state of the ﬁle system represented by the in-core information. The disk information is updated tore ect the in-core information when the buffer is required for another use, when a sync(2) is done (at 30 second intervals) by /etc/update(8), or by manual operator intervention with the sync(8) command. If the system is halted without writing out the in-core information, the ﬁle system on the disk will be in an inconsistent state. If all updates are done asynchronously, several serious inconsistencies can arise. One inconsistency is that a block maybe claimed by two inodes. Such an inconsistency can occur when the system is halted
The UNIX File System Check Program SMM:3-5 before the pointer to the block in the old inode has been cleared in the copy of the old inode on the disk, and after the pointer to the block in the new inode has been written out to the copy of the new inode on the disk. Here, there is no deterministic method for deciding which inode should really claim the block. A similar problem can arise with a multiply claimed inode. The problem with asynchronous inode updates can be avoided by doing all inode deallocations synchronously. Consequently, inodes and indirect blocks are written to the disk synchronously (i.e. the process blocks until the information is really written to disk) when they are being deallocated. Similarly inodes are kept consistent by synchronously deleting, adding, or changing directory entries.