Ric Wheeler wrote: > After today's call, I was poking around a bit to try and understand > better how the async commit code plays with the write barrier. > > journal_submit_commit_record seems to disable the barriers when async IO > is enabled if I read the code correctly. If this is true, how can we > provide any promises of on disk data integrity after an fsync()? > > Regards, > > Ric 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? -Eric -- 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
