Journaled filesystems and power failure
I heard that even a journaled filesystems such as EXT3/EXT4 might corrupted during power failure, e.g. from wikipedia [1]:
In the event of a system crash or power failure,
such file systems are quicker to bring back online and
less likely to become corrupted.
Can anyone provide more detail by giving examples such that when
- corruption can occur
- corruption is avoided by journaled filesystems
[1] http://en.wikipedia.org/wiki/Journaling_file_system
Corruption can also occur on most modern disks due to in-disk re-ordering.
Modern disks typically do re-ordering of requests that are used to speed up performance (by re-ordering writes to make the entire list of requests less seeky), this is called Tagged Command Queueing.
It is possible the write to the journal on the disk is delayed because its more efficient from the head position currently to write in a different order to the one the operating system requested as the actual order, meaning blocks can be committed before the journal is.
The way to resolve this is to make the operating system explicitly wait for the journal to have been committed before committing any more writes. This is known as a barrier. Most filesystems do not use this by default and would explicitly need enabling with a mount option.
mount -o barrier=1 /dev/sda /mntpnt
The big downside to barriers is they have a tendency to slow I/O down, sometimes dramatically (around 30%) which is why they arent enabled by default. In addition to this, things become doubleplusungood when you start to add logical layering on top of standard disks like LVM or Raid. LVM (relatively recently) added barrier support for most LV configurations and mdadm seems to have had it for a little while.
Most journaled file systems (ext3/4, ntfs) only transactionally protect the meta data. If a power outage occurs, user data could be rendered inconsistent but the meta data is fine.
Zfs and I think xfs protect both meta data and user data using transactions and logs.