linux-ext4 - Re: async commit & write barrier code

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, 23 Sep 2008 18:35:05 -0400
From:	Theodore Tso <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Ric Wheeler <rwheeler@...hat.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: async commit & write barrier code

On Tue, Sep 23, 2008 at 03:41:02PM -0500, Eric Sandeen wrote:
> 
> I agree; with async commit, ext4/jbd2 is running with *no* barrier
> writes in jbd code. (FWIW, on the fsync front, fsync calls
> blkdev_issue_flush in ext4 so that part may actually be ok in the end).
> 
> But at a minimum, I think that for data=ordered, there is now *no*
> guarantee that the associated file data actually hits disk before the
> size updates, is there?

I think the theory behind this was that the journal checksums would
protect us against misordered writes.  But yes, this means that we
would effectively have data=writeback, and not data=ordered.  More
seriously, when I started using my root filesystem with async commit,
when the system crashed after suspend/resumes, I was seeing filesystem
corruptions which caused data loss and which required e2fsck to fix.
I've commented the patch out of the series file for now, until we can
do some more testing of async commit.

							- Ted
--
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