Most modern Linux file systems, including Ext3 and Ext4, include file system barriers as a security feature. They protect data written to the journal. But, in many cases it is unclear if these barriers are useful. This tip explains why you might want to consider using them on your Linux system.
Linux journals and barriers
To understand barriers, you need to understand file system journals. Modern file systems use journals to ensure file system integrity. The idea behind journaling is simple: before writing the actual data blocks to disk, the file system metadata are written to the journal. Writing the metadata first guarantees that if something goes wrong during or before the writing of the data blocks, the journal can easily recover from the situation. This approach guarantees that no file system corruption will occur.
To understand barriers, you need to understand file system journals. Modern file systems use journals to ensure file system integrity. The idea behind journaling is simple: before writing the actual data blocks to disk, the file system metadata are written to the journal. Writing the metadata first guarantees that if something goes wrong during or before the writing of the data blocks, the journal can easily recover from the situation. This approach guarantees that no file system corruption will occur.
Using a journal alone doesn't guarantee nothing will go wrong. Modern disk have large caches and data is not written to disk immediately, but to the disk cache first. Once there, the disk controller can decide to reorder the data blocks to write them more efficiently. This is good for performance, but bad for journaling. For the journal to be 100% reliable, there must be an absolute guarantee that the metadata have been committed to disk before the data blocks are written. That's why file system barriers have been introduced.
The essence of using barriers is easy to understand: a barrier forbids the writing of blocks that come after the barrier, until all blocks that have been written before the barrier was issued are really written to disk. Using barriers ensures the integrity of the file system journal, and because of this barriers are enabled by default in the Ext4 file system (unless your distribution has changed this default).
Checking Linux file system barriers: on or off?
You can monitor the current status of the file system barriers through the /proc/mounts file; for each of the mounted file systems this file shows all mount options. If you see barrier=1, your file system is using barriers. The listing below shows an example of what this looks like for the relevant file systems.
You can monitor the current status of the file system barriers through the /proc/mounts file; for each of the mounted file systems this file shows all mount options. If you see barrier=1, your file system is using barriers. The listing below shows an example of what this looks like for the relevant file systems.
/dev/sda1 /boot ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0
/dev/mapper/luks-3e67401f-44c6-4a27-a1bf-cdf0dcf45f65 /home ext4 rw,seclabel,noatime,barrier=1,data=ordered 0 0
When file system barriers don't work
The problem with barriers is that they can't be used in all cases. File system barriers won't work if the device mapper is used as the underlying storage layer because device mapper doesn't support barriers. So, even if your file system is using barriers by default they are not operational on file systems that are on logical volumes (the default on Red Hat and all related distributions), on software RAID, or on multipathd volumes.
The problem with barriers is that they can't be used in all cases. File system barriers won't work if the device mapper is used as the underlying storage layer because device mapper doesn't support barriers. So, even if your file system is using barriers by default they are not operational on file systems that are on logical volumes (the default on Red Hat and all related distributions), on software RAID, or on multipathd volumes.
One solution for this is to avoid device mappers. So, when installing a server, you need to consider your options. First, you have to avoid installing your server with LVM and use traditional partitions instead. Next, you have to avoid the Linux multipathd driver which works with device mapper and is used to create redundant paths to a SAN. In some cases your SAN vendor will provide a proprietary driver as an alternative, but that's not always the case. The best option is the use of clever hardware.
The risk that barriers protect against is that during an outage the data remains in the disk cache and never makes it to the file system. A simple battery backed controller avoids this risk. If a server using such a controller fails, the disk controller is still able to commit changes, which completely eliminates the use for barriers.
Another disadvantage of using barriers is that you will pay a performance price. If you need top performance in your environment, you can switch off barriers completely by using the mount option -o barrier=0; for instance: mount /dev/sda2 -o barrier=0 /data.
File system barriers are useful, but can't work together with device mapper devices. If you need to use these devices, but want to ensure file system integrity, you can use battery backed disk controllers. In case your hardware doesn't provide this, avoid device mapper so that you can use barriers to guarantee file system integrity. Also if you want the best possible performance, it's best to avoid barriers, as they slow down your system.
