What does the 'barrier' mount flag mean in Linux?

Question

The manual for the 'barrier' mount option is:

barrier=0 / barrier=1

This disables / enables the use of write barriers in the jbd code.barrier=0 disables, barrier=1 enables (default). This also requires an IO stack which can support barriers, and if jbd gets an error on a barrier write, it will disable barriers again with a warning. Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty. If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.

But I do not know what the sentence "proper on-disk ordering of journal commits" means.

Suppose normal order -- journal 1,data 1; journal 2, data 2.
Which of the following ordering results will happen if I set barrier=0?

1. journal 2, data 2; journal 1, data 1;
2. data 1, journal 1; data 2, journal 2.

Answer 1

Most modern file systems are journaling file systems, which means that they keep track of changes that have not yet been written to disk in an internal data structure called a journal. In the event of a crash, this journal will be replayed, to make sure that all writes performed successfully, preventing file corruption.

When actually writing out the data to disk, the write cache will re-order the writes to try to maximize the throughput, but it must make sure that the actual file data is written to disk before the metadata, to make sure that if a crash occurs the metadata won't be out-of-date with the data.

The problem is that many disks have caches of their own that might re-order the writes as well. Some file systems will assume that that will happen and will force the disk to flush the cache at certain points to prevent this, and is called write barriers in e.g. ext4, and Linux in general.

For modern disks the performance sacrifice for doing this is negligible though, and you shouldn't disable write barriers unless absolutely necessary.

Answer 2

From this LWN article:

The filesystem code must, before writing the [journaling] commit record, be absolutely sure that all of the transaction's information has made it to the journal. Just doing the writes in the proper order is insufficient; contemporary drives maintain large internal caches and will reorder operations for better performance. So the filesystem must explicitly instruct the disk to get all of the journal data onto the media before writing the commit record; if the commit record gets written first, the journal may be corrupted. The kernel's block I/O subsystem makes this capability available through the use of barriers; in essence, a barrier forbids the writing of any blocks after the barrier until all blocks written before the barrier are committed to the media. By using barriers, filesystems can make sure that their on-disk structures remain consistent at all times.