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 <[email protected]> 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.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
