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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
