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]
Date:	Thu, 16 Dec 2010 15:11:36 -0500
From:	Ric Wheeler <ricwheeler@...il.com>
To:	Olaf van der Spek <olafvdspek@...il.com>
CC:	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: Atomic non-durable file write API

On 12/16/2010 07:22 AM, Olaf van der Spek wrote:
> On Thu, Dec 9, 2010 at 1:03 PM, Olaf van der Spek<olafvdspek@...il.com>  wrote:
>> Hi,
>>
>> Since the introduction of ext4, some apps/users have had issues with
>> file corruption after a system crash. It's not a bug in the FS AFAIK
>> and it's not exclusive to ext4.
>> Writing a temp file, fsync, rename is often proposed. However, the
>> durable aspect of fsync isn't always required and this way has other
>> issues.
>> What is the recommended way for atomic non-durable (complete) file writes?
>>
>> I'm also wondering why FSs commit after open/truncate but before
>> write/close. AFAIK this isn't necessary and thus suboptimal.
> Somebody?
>
> Olaf

Getting an atomic IO from user space down to storage is not really trivial.

What I think you would have to do is:

(1) understand the alignment and minimum IO size of your target storage device 
which you can get from /sys/block (or libblkid)

(2) pre-allocate the file so that you do not need to update meta-data for your write

(3) use O_DIRECT write calls that are minimum IO sized requests

Note that there are still things that could break your atomic write - failures 
in the storage device firmware, fragmentation in another layer (breaking up an 
atomic write into transport sized chunks, etc).

In practice, most applications that need to do atomic transactions use logging 
(and fsync()) calls I suspect....

Was this the kind of answer that you were looking for?

Ric

--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ