File systems in the OS have mechanisms to persist despite abrupt power changes, thereby handling the problem of crash consistency. To understand the crash scenario, assume that a user has given the “write” instruction onto the disk, and in between the process someone unplugs the power cord. The disk was only partially updated. The user then reboots the system, expecting the file system to get mounted again.
Consider an instance where the user wishes to append a single data block (4KB) to an existing file. The figure below denotes the state before the append (white blocks are empty, while the green ones denote containing data).
When a disk block is written, there are 3 updates done to the file system:
- Inode is updated.
- Data bitmap gets updated.
- New data block is allocated.
The figure below shows the state after the append (red blocks denote updates).
However, these updates do not happen atomically. Therefore, the following cases may arise:
- Only the Inode update gets written to disk:
In this case, the Inode will point to the data block, but since the new data was never written, it will read old garbage contents from the address. This leads to file system inconsistency.
- Only data block gets written to the disk:
In this case, there is data on the disk but there is no Inode to refer to it. This is equivalent to the case of no write having occurred at all. The system is NOT in an inconsistent state.
- Only updated bitmap gets written to the disk:
In this case, the bitmap shows that the data block has been written, but there is no Inode that points to it. This essentially wastes space on the data block (because that block will never be used to store any more data). This causes space leak as well as file system inconsistency.
- Only Inode and data bitmap get written to the disk:
In this case, there is no data written into the disk. So, even though the file metadata is correct, there will be old garbage values retrieved upon access.
- Only Inode and data block get written to the disk:
In this case, there is an inconsistency between the Inode and the bitmap.
- Only bitmap and data block get written to the disk:
In this case, again there is an inconsistency between the Inode and the data bitmap. We have some data lying somewhere but we don’t know which file it belongs to.
Solutions to the Problem:
There are two standard solutions to the problem of file system inconsistency — File System Checker (FSCK), a traditional approach, and a more modern approach called journaling (or write-ahead logging).