Barriers and journaling filesystems
Posted May 23, 2008 16:55 UTC (Fri) by jlokier
Parent article: Barriers and journaling filesystems
A couple of clarifications.
...contiguous space is easy to come by. Keeping the journal together will be good for performance, but it also helps to prevent reordering. In normal usage, the commit record will land on the block just after the rest of the journal data, so there is no reason for the drive to reorder things. The commit record will naturally be written just after all of the other journal log data has made it to the media.
That helps only with the first
barrier, before the commit block. There's a better way to eliminate that barrier, which is a checksum in the commit block and ext4 does do that.
You still need the second barrier, somewhere after the commit block, because it orders the journal write against writes elsewhere on the disk - those are never contiguous.
Disabling the write cache avoids this whole barrier problem, because writes can't be reordered then
It's not clear if disabling write cache is enough, when ext3 is mounted with barrier=0 (the current default). That stops the disk
from reordering writes, but the kernel elevator
is still able to reorder writes, when barrier=0, before sending them to the disk. Setting barrier=1 has the dual effect of telling the kernel not to reorder requests around barrier writes, and ideally passing that constraint to the disk as well.
Disabling barriers on xfs increases performance very very much in some situations, especially when deleting a directory tree with many small files, eg the linux-2.6 tree. With barriers it takes something like 2-3 minutes and without barriers around 20 seconds. (These numbers are
from my memory).
That suggests a flaw in the way XFS implements deletions. There is no reason to require so many barriers. The only thing which should be able to cause a high rate of barriers is a high rate of fsync() calls (which aren't done in this case) or the journal being too small.
to post comments)