On Aug 25, 2009 17:11 -0400, Theodore Ts'o wrote: > The problem is without my patch, the barrier=1 mount option is > completely ignored, and there's no way to enable barriers with > async_commit --- which is clearly wrong. So with my patch, it now > becomes safe for people to experiment with async_commit --- and if > they also to experiment with the barrier=0 w/ "hdparm -W 0" they can > do so. For any given workload and hardware combination, there is > therefore three safe configuarions that people can try benchmarking: > > !async_commit,barrier=1,"hdparm -W 1" (currently the default) > async_commit,barrier=1,"hdparm -W 1" > async_commit,barrier=0,"hdparm -W 0" > > (n.b., !async_commit,barrier=0,"hdparm -W 0" is not completely safe, > since without the barrier, it's possible, although granted not very > likely, for the block layer elevator algorithm to reorder blocks in > block device queue.) I'm not sure I understand about the "n.b." case. If the filesystem is running with !async_commit,barrier=0,wcache=0 (which is basically ext3 with write cache off), it should still have the jbd code doing an explicit wait for the data blocks (which should be guaranteed to make it to disk, wcache being off) before even submitting the commit block to the elevator? It doesn't matter what order the transaction blocks are written to disk, so long as the commit block is last. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
