Messages in this thread | | | Date | Tue, 20 May 2008 16:43:14 +0100 | From | Jamie Lokier <> | Subject | Re: [PATCH 4/4] ext4: call blkdev_issue_flush on fsync |
| |
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
| |