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 _______________________________________________ Ocfs2-users mailing list Ocfs2-users@oss.oracle.com http://oss.oracle.com/mailman/listinfo/ocfs2-users