Re: Atomic non-durable file write API

[Nick Piggin <npiggin@gmail.com>]

On Mon, Dec 27, 2010 at 2:23 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Sun, Dec 26, 2010 at 10:59 AM, Amir Goldstein <amir73il@gmail.com> wrote:
>> Whether or not the new data is durable is entirely up to the
>> programmer to decide.
>
> Right
>
>> Perhaps all that is missing is an fdatawait(fd) API or fdatawait_async(fd) API,
>> which should be very simple to implement (right?).
>>
>> So an editor that doesn't want to be too pushy, will just save a temp file,
>> wait for it to sync on the system's free time and then swap the data with
>> the original file in an atomic manner, which preserves metadata.
>>
>> If the system takes too long to sync, the editor can always issue
>> fdatasync(fd) when it is tired of waiting.
>>
>> Will that make you happy, Olaf?
>> If you are not happy from the new copy not being available to all
>> system users until
>> fdatasync is done, then we will call it "atomic, isolated non-durable
>> file write API", OK?
>
> No. Take the compiler case. Ideally you'd like file data updates to be
> atomic, but waiting until an update hits disk before it's visible to
> other processes is unacceptable.

How about sending output to an intermediate name, then before it is
used in the next stage of the processor output, fsync+rename to the
expected name? make clean would delete any intermediate names.