Peter W. Morreale wrote:> Can someone explain the implications of the "barrier=[0,1]" mount
option
> in OCFS2?
A common misconception with disks is that when it acknowledges a write,
that that write has hit the platter. This is not the case with disks that
have their own caches. Earlier it was not an issue because enterprise disks
have their own battery packs with enough juice to drain the cache to the
platter. But increasingly consumer grade disks are bulking up their cache
sizes (for performance) but lack the requisite battery packs.
What this means is that powering off a machine could result in corrupting a
file system. And that is because journaled file systems expect the journal
writes to be ordered. Specifically, the commit block should not hit the
platter until all other blocks in that transaction have.
A barrier ensures all writes to a disk have hit the platter. We use this in
journaling by calling it before and after the commit block write.
The biggest implication is performance. Enabling it always leads to lower
performance. On the upside, there is lower probability of a fs corruption
after a force power down. I believe btrfs, ext4 and xfs enable it by
default.
ocfs2 does not enable it by default because our users are typically
using shared
storage that is electrically isolated from the servers. Powering down a
node does
not power down the storage. Also, one would think that the shared
storage has
quality disks.
Oh btw, enabling it is useless if the disk (or any software layer) does not
support it. For example, support in md/dm is a work-in-progress.
Hope this helps.
Sunil