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]

Date:	Wed, 26 Aug 2009 16:00:45 -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 26, 2009  09:14 -0400, Theodore Ts'o wrote:
> On Wed, Aug 26, 2009 at 03:50:35AM -0600, Andreas Dilger wrote:
> > I'm not sure I understand about the "n.b." case.  If the filesystem
> > is running with !async_commit,barrier=0,"hdparm -W 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.
> 
> Gack, sorry, I screwed that up.  What I should have written is this:
> 
> The safe configurations people could try benchmarking:
> 
>       !async_commit,barrier=1,"hdparm -W 1"	(currently the default)
>       !async_commit,barrier=0,"hdparm -W 0"
>       async_commit,barrier=1,"hdparm -W 1"
> 
> and the unsafe case in the nb should have been <async_commit,
> barrier=0, "hdparm -W 0">, since without the barrier, async_commit
> writes the commit block at the same time as the rest of the journal
> (data, metadata, and revoke) blocks, and so there is the chance the
> commit block could get reordered in front of the other journal blocks.

I'm still missing something.  With async_commit enabled, it doesn't
matter if the commit block is reordered, since the transaction checksum
will verify if all of the data + commit block are written for that
transaction, in case of a crash.  That is the whole point of async_commit.
If the commit block is on disk, but there are some transaction blocks
missing the checksum will (except in very rare coincidences) fail and the
transaction is skipped.  With "hdparm -W 0" we are guaranteed to only
have a single uncommitted transaction, except in the case of journal
corruption (i.e. disk error or software bug).

I can imagine with "async_commit,barrier=0,"hdparm -W 1" that having
multiple transactions begin checkpointing before they are fully
committed, which means the filesystem is modified in a non-recoverable
way.

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