25

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.
Mat
  • 51,578
  • 10
  • 158
  • 140
leafonsword
  • 375
  • 1
  • 3
  • 9
  • http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/block/barrier.txt?id=09d60c701b64b509f328cac72970eb894f485b9e is probably a worthwhile read. – Håkan Lindqvist Jul 21 '14 at 14:04
  • 1
    If you read about journaling filesystems, then you will realise that it is important to write the journal first, then execute the journal thus writing the real data to disk. The barrier ensures that the journal is written before it is executed. Otherwise the journal us useless. – ctrl-alt-delor Jul 21 '14 at 16:14
  • @richard When using "nobarrier" flag in BBWC hard raid,then disk couldn't ensure journal is written before its data is executed,does this condition not matter? – leafonsword Jul 22 '14 at 03:22
  • I don't know enough to know if it matters. I would think that at worse it is as bad as no journal, but what I have read it does not seem that bad, however I can not discern the subtleties. I have `barrier=1`, and it runs fast enough for me. Unless you are doing real heavy duty stuff I would leave it on. You have ram buffers so stuff will be written out when it can, with *no* slowdown to applications. And very little delay in writing to disk. If you with to see how much the ram buffers speed things up then add sync=1 to your home directory, and try to use your system for a day or two. – ctrl-alt-delor Jul 22 '14 at 09:06

2 Answers2

20

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.

remmy
  • 4,955
  • 1
  • 23
  • 30
4

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.

G-Man Says 'Reinstate Monica'
  • 22,130
  • 27
  • 68
  • 117
qinganfan
  • 41
  • 1