lkml.org 
[lkml]   [2008]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-05-20 17:47    [W:0.128 / U:0.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site