linux-ext4 - Re: Atomic non-durable file write API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTi=OqXqa+76H2f8oygm1Y6iZUY+NZ=K3Sp_x=AfH@mail.gmail.com>
Date:	Sun, 26 Dec 2010 11:59:43 +0200
From:	Amir Goldstein <amir73il@...il.com>
To:	Olaf van der Spek <olafvdspek@...il.com>
Cc:	Dave Chinner <david@...morbit.com>, "Ted Ts'o" <tytso@....edu>,
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: Atomic non-durable file write API

On Fri, Dec 24, 2010 at 12:47 AM, Ted Ts'o <tytso@....edu> wrote:
> On Fri, Dec 24, 2010 at 09:43:09AM +1100, Dave Chinner wrote:
>>
>> So you are looking for something like:
>>
>> http://developer.apple.com/library/mac/#DOCUMENTATION/Darwin/Reference/ManPages/man2/exchangedata.2.html
>>
>
> It doesn't look like the man page for exchangedata() states what
> happens if the system crashes.  It says "atomic" the same way the
> rename() system call says it is "atomic".... i.e., from the
> perspective of processes running on the system see either the
> pre-exchange or post-exchange state.
>

Since we already have EXT4_IOC_MOVE_EXT ioctl, it might as well be
used for the purpose of 'safe save'
in the same manner that exachangedata() works.

Whether or not the new data is durable is entirely up to the
programmer to decide.
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?

Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html