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:	Tue, 25 Aug 2009 11:52:47 -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 24, 2009  20:15 -0400, Theodore Ts'o wrote:
> On Mon, Aug 24, 2009 at 05:43:36PM -0600, Andreas Dilger wrote:
> > Without transaction checksums waiting on all of the blocks together
> > is NOT safe.  If the commit record is on disk, but the rest of the
> > transaction's blocks are not then during replay it may cause garbage
> > to be written from the journal into the filesystem metadata.
> 
> That's the one optimization we using journal checksums buys us.
> Unfortunately it does not allow us to omit the barrier
> operation.... and have real-world testing experience that without the
> barrier, a power drop can cause significant filesystem corruption and
> potential data loss.
> 
> Try using Chris Mason's torture-test workload with async-checksums
> without this patch; you will get data corruption if you try dropping
> power while his torture-test is running.  I know you really don't like
> the barrier, but I'm afraid it's not safe to run without it, even with
> journal checksums.

In our performance testing of barriers (not with Chris' program), it
was FAR better to disable the disk cache and wait for IO completion
(i.e. barriers disabled) on just the journal blocks than to enable the
cache and cause a cache flush for each "barrier".  The problem is that at
high IO rates there is much more data in the cache vs. the actual journal
blocks, and forcing the whole cache to be flushed each transaction commit
hurt our performance noticably.

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

Powered by blists - more mailing lists