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: <AANLkTikHMZDyNkaOux5VWUHvC5D1cXHEFKxhvzfVjN+Q@mail.gmail.com>
Date:	Sat, 25 Dec 2010 22:33:59 +1100
From:	Nick Piggin <npiggin@...il.com>
To:	Olaf van der Spek <olafvdspek@...il.com>
Cc:	"Ted Ts'o" <tytso@....edu>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-ext4@...r.kernel.org
Subject: Re: Atomic non-durable file write API

On Sat, Dec 25, 2010 at 9:41 PM, Olaf van der Spek <olafvdspek@...il.com> wrote:
> On Sat, Dec 25, 2010 at 4:15 AM, Ted Ts'o <tytso@....edu> wrote:
>> On Fri, Dec 24, 2010 at 12:14:21PM +0100, Olaf van der Spek wrote:
>>>
>>> Thanks for taking the time to answer. The thread was started due to
>>> the dpkg issue.
>>
>> I've talked to the dpkg folks and I believe they are squared away; for
>> their use case sync_file_range() combined with fsync() should solve
>> their reliability and performance problem.
>
> It's not just about dpkg, I'm still very interested in answers to my
> original questions.

Arbitrary atomic but non-durable file write operation? That's significantly
different to how any part of the pagecache or filesystem or syscall API
is set up. Writes are not atomic, and syncs are only for durability (not
atomicity), atomicity is typically built on top of these durable points.

That is quite fundamental functionality and suits simple
implementations of filesystems and writeback caches.

If you start building complex atomicity semantics, then you get APIs
which can't be supported by all filesystems, Linux specific, adds
complexity from the API through to the pagecache and to the
filesystems, and is Linux specific.

Compare that to using cross platform, mature and well tested sqlite
or bdb, how much reason do we have for implementing such APIs?

It's not that it isn't possible, it's that there is no way we're adding
such a thing unless it really helps and is going to be widely used.

What exact use case do you have in mind, and what exact API
semantics do you want, anyway?
--
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