Re: Enable asynchronous commits by default patch revoked?

[Andreas Dilger <adilger@sun.com>]

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.