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:	Mon, 24 Aug 2009 15:28:40 -0600
From:	Andreas Dilger <adilger@....com>
To:	Theodore Tso <tytso@....edu>
Cc:	Christian Fischer <Christian.Fischer@...terngraphics.com>,
	linux-ext4@...r.kernel.org
Subject: Re: Enable asynchronous commits by default patch revoked?

On Aug 24, 2009  16:10 -0400, Theodore Ts'o wrote:
> However, even if we add even if we add per-block checksums, there is
> still the problem that there is logic in the jbd layer where we avoid
> reusing certain blocks until we are sure the transaction has
> committed.  With asynchronous commits, there is no way of knowing when
> it is safe to reuse those blocks.  

AFAIK, "async commits" are not wholly async.  There is still a wait
for the transaction commit block to hit the disk before calling the
transaction committed.  The main improvement with "async commits" is
that JBD only waits ONCE for both the transaction data blocks and the
commit block (which are submitted at the same time).  In particular
note that there is an unconditional wait on the commit block for
every transaction commit.

JBD currently submits the transaction data and waits once for them
to complete, and then submits the commit block and waits a second time
for it to complete, which is 2x latency for every transaction.

> Looking at the code, the best we can do in the short-term is to write
> the commit record where we do, but do so with a barrier requested, and
> then wait for the commit block where we do.  This will provide some
> performance improvement, since we won't wait for all of the journal
> blocks to be sent to disk before writing the commit record.

The big problem with Linux "barriers" is that they are actually cache
flushes, so are worse than just having the original code that waits
for completion of the actual journal blocks, because the "barrier"
will force all kids of unrelated blocks to disk as well.

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