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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 27 Dec 2010 16:30:14 +0100
From:	Christian Stroetmann <stroetmann@...olinux.com>
To:	Olaf van der Spek <olafvdspek@...il.com>
CC:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-ext4@...r.kernel.org, Ted Ts'o <tytso@....edu>,
	Nick Piggin <npiggin@...il.com>
Subject: Re: Atomic non-durable file write API

On the 27.12.2010 11:21, Olaf van der Spek wrote:
> On Sun, Dec 26, 2010 at 11:10 PM, Ted Ts'o<tytso@....edu>  wrote:
>> On Sun, Dec 26, 2010 at 07:51:23PM +0100, Olaf van der Spek wrote:
>>> f = open(..., O_ATOMIC, O_CREAT, O_TRUNC);
>> Great, let's rename O_ATOMIC to O_PONIES.  :-)
> If that makes you happy.
>
>>> abort/rollback(...); // optional
>> As I said earlier, "file systems are not databases", and "databases
>> are not file systems".  Oracle tried to foist their database as a file
>> system during the dot.com boom, and everyone laughed at them; the
>> performance was a nightmare.  If Oracle wasn't able to make a
>> transaction engine that supports transactions and rollbacks
>> performant, you really expect that you'll be able to do it?
> Like I've said dozens of times, this is not about full DB functionality.
> Why do you keep making false analogies?

The analogy is not so wrong. The concepts atomicity and abort/rollback 
your are talking about are also concepts of the field of database 
management systems (DBMSs). And once you have established the Atomicity, 
which is the A of the principle ACID of DBMSs, you have the basis for 
establishing the rest, the CID.

And you even went further into this DBMS direction by letting down the 
requirement of non-durability.

<snip>

>>> Providing transaction semantics for multiple files is a far broader
>>> proposal and not necessary for implement this proposal.
>> But providing magic transaction semantics for a single file in the
>> rename is not at all clearly useful.  You need to justify all of this
>> hard effort, and performance loss.  (Well, or if you're so smart you
>> can implement your own file system that does all of this work, and we
>> can benchmark it against a file system that doesn't do all of this
>> work....)
> Still waiting on any hint for why that performance loss would happen.

 From my point of view, the loss of performance depends on what is 
benchmarked in which way.

<snip>

> Olaf
> --

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