Re: async commit & write barrier code

[Theodore Tso <tytso@mit.edu>]

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