linux-ext4 - Re: Enable asynchronous commits by default patch revoked?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <20090826095035.GH5931@webber.adilger.int>
Date:	Wed, 26 Aug 2009 03:50:35 -0600
From:	Andreas Dilger <adilger@....com>
To:	Theodore Tso <tytso@....edu>
Cc:	Ric Wheeler <rwheeler@...hat.com>,
	Christian Fischer <Christian.Fischer@...terngraphics.com>,
	linux-ext4@...r.kernel.org
Subject: Re: Enable asynchronous commits by default patch revoked?

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html