Re: Bug#605009: serious performance regression with ext4
On Sat, Nov 27, 2010 at 03:54:12PM +0100, Olaf van der Spek wrote:
> On Fri, Nov 26, 2010 at 10:52 PM, Ted Ts'o <tytso@mit.edu> wrote:
> > I am guessing you are doing (a) today --- am I right? (c) or (d)
> > would be best.
>
> Are there any plans to provide an API for atomic (non-durable) file
> updates, not involving fsync?
> Would be simpler (for apps), faster and more general (because it makes
> less assumptions).
In fact, fsync() or fdatasync() is rarely what one needs. A syscall that
was proposed several times in various versions would be:
barrier(fda, fdb)
which ensures that all past writes to fda are no less durable than future
writes to fdb (which may be equal to fda). That would handle all cases I
can think of -- stuff that would require ordering writes to part of the file
and can't be handled by this version of barrier() nearly always wants an
actual ranged fsync (fsync_range() on BSD, sync_file_range() on Linux).
Such a syscall can be added right away -- if the underlying filesystem
doesn't support it yet or the files are on different filesystems, it
could quietly degrade to fdatasync().
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Reply to: