Re: [PATCH 4/4] ext4: call blkdev_issue_flush on fsync

On Tue, May 20 2008, Eric Sandeen wrote:

Jamie Lokier wrote:

quoted

Theodore Tso wrote:

quoted

On Fri, May 16, 2008 at 02:09:56PM -0500, Eric Sandeen wrote:

quoted

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.

I think that might still be true, but I'm still looking through it (in
the background...)

I tried blktrace to see what was going on but I'm not sure what an "NB"
in the RWBS field means, anyone know?

Eric already knows this now, but for the benefit of anyone else that may
be curious - it's an empty (data-less) barrier. 'N' is basically 'no
data' (eg not a read nor a write) and 'B' is barrier.

-- 
Jens Axboe