There are various levels of corruption resistance in file systems in the event of loss of power, from least to most corruption-resistant.
File systems with no journalling.
Examples: ext2
, fat32
, fat16
Such file systems have no protection against file system corruption due to loss of power. After a power loss during a write, the metadata for the file may be in an inconsistent state, meaning that the file system is effectively corrupted and needs repair. A repair won't necessarily be able to successfully recreate a file's metadata from a single point in time. In some cases, for example, a repair tool may not be able to know certain details about a file.
File systems with a writeback journalling mode.
Examples: ext3
/ext4
with data=writeback
, NTFS
Writes to the metadata for files is journalled. After a power loss during a write, the metadata for the file can be rolled back leaving the file system in a consistent state requiring no repair. However, any changes to the actual data of a file won't be able to be rolled back and the file may be left in an inconsistent state.
A file may even be left with old data from before a write operation even if its metadata is successfully committed.
File systems with an ordered journalling mode.
Examples: ext3
/ext4
with data=ordered
Pretty similar to the writeback mode. Writes to the metadata for files is journalled, and the system ensures that the file data is written before the metadata change is committed in the journal. After power loss during a write, the metadata can be rolled back leaving the file system in a consistent state requiring no repair. Any changes to the actual data of a file won't be able to be rolled back and the file may be left in an inconsistent state.
Where this differs from the writeback mode is that you at least will never be left with older data in a file than its metadata, and will never be left with data that previously didn't belong to that file. If metadata is committed, then it is guaranteed that the file data is at least up to date with the metadata, though it may still contain some newer data from part of a later write to that file.
Having this constraint can improve security and improves the ability for applications to implement their own data integrity measures that rely on the metadata for the file at least reflecting a write that was made to the file at some stage.
File systems with full journalled mode.
Examples: ext3
/ext4
with data=journal
, Reiser4
Writes to both the metadata and all file data are both journalled. After power loss during a write, both the file's metadata and all its data can be rolled back to the state it was in prior to the failure.
This mode has the highest performance penalty because all data must be written twice, effectively cutting throughput in half. Thus, it is rarely used. Applications that rely on data integrity can take their own measures to ensure file data can be recovered from an inconsistent state, as long as they can trust the metadata on files.
Special mention: log-structured file systems or copy-on-write
Examples: btrfs
, ZFS
Some file systems such as btrfs offer similar protection to a full journalled file system without as much performance penalty. btrfs
is a log-structured file system. Writes to both the metadata and all file data are written to a big long write log which allows both file metadata and contents to be rolled back completely, but this requires no separate "commit" step for the file data, as the file data is duplicated as it's written to, allowing for rollback without writing twice. If a write fails due to a power loss, the log is only replayed to the last successful write prior, which will still provide access to the old version of the file in its fully consistent state.
ZFS
is a copy-on-write filesystem which has similar benefits to a log-structured file system.
Note: Write caching and Barriers
Regardless of the file system, write caching on the drive itself may optimise performance by performing queued write commands in a different order to their place in the queue. However, this would effectively render all journalling useless, or at least all journalling modes other than writeback which is unlikely to be affected much by this optimization.
To combat this however, drives have implemented a concept of "write barriers" where the computer can tell the drive that it must complete all previous writes before a particular write can begin. Modern operating systems use write barriers to ensure that journalling file systems benefit properly from the integrity offered by journalling. In typical file write operations write barriers lose most of the performance benefit you would have gained from the drive's ability to perform writes out of order, but certain applications such as some database servers may still benefit from this even with write barriers enabled.
Write barriers can be disabled in the mount options for a partition but you probably don't want to do this if you are using one of the better journalling modes such as ordered or full journalling.
Some disk drives are designed with their own dedicated back-up-battery which can be used to finish any writes in the write queue in the event of a power loss. If you have such a drive and trust the back-up battery to do this, you can safely disable write barriers and benefit more from out-of-order writes in the drive.
The current default for Ubuntu is ext4
which has an ordered journalling mode. This is much better than no journalling at all, because the file system itself won't be left in a corrupted state, and it's a step up over writeback, because it guarantees that if a file's metadata is updated, its contents have been updated. Note that the default for ext3
was changed to writeback a few years back.
btrfs
was designed as a replacement for ext3/4
, and future Linux distributions may switch to it as a default, though that is not a certainty. If this does happen, it will bring better ability to cleanly rollback with no significant performance penalty.