Theodore Tso wrote: > On Fri, May 16, 2008 at 02:09:56PM -0500, Eric Sandeen wrote: > > To ensure that bits are truly on-disk after an fsync, > > we should call blkdev_issue_flush if barriers are supported. > > This patch isn't necessary, and in fact will cause a double flush. > When you call fsync(), it calls ext4_force_commit(), and we do a the > equivalent of a blkdev_issue_flush() today (which is what happenes > when you do a submit_bh(WRITE_BARRIER, bh), which is what setting > set_ordered_mode(bh) ends up causing. ISTR fsync() on ext3 did not always force a commit, if in-place data writes did not change any metadata. Has this been fixed in ext4 but not ext3 then? Does WRITE_BARRIER always cause a flush? It does not have to according to Documentation/block/barrier.txt. There are caveats about tagged queuing "not yet implemented" in the text, but can we rely on that? The documentation is older than the current implementation; those caveats might no longer apply. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
