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]

Date:	Wed, 29 Dec 2010 17:30:19 +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 <linux-ext4@...r.kernel.org>,
	Ted Ts'o <tytso@....edu>, Neil Brown <neilb@...e.de>,
	Nick Piggin <npiggin@...il.com>
Subject: Re: Atomic non-durable file write API

On the 29.12.2010 16:41, Olaf van der Spek wrote:
> On Wed, Dec 29, 2010 at 4:30 PM, Christian Stroetmann
> <stroetmann@...olinux.com>  wrote:
>>> True, I don't understand why people say it will cause a performance
>>> hit but then don't want to tell why.
>> We are talking about atomicity. And it is a simple fact in the field of
>> information processing/informatics/computer science that if someone wants to
>> give/have the guarantee of atomicity, then she/he has to do several
>> additional steps often by using an additional data structure. In the end
> Additional steps compared to what? The temp file, fsync, rename case?

read the paragraphs as a whole

>> this all costs more time and/or space than doing it without atomicity. At
> Of course. But this should not affect the non-atomic usage.

read the whole paragraphs again

>> this point there is no discussion anymore, because this is fully discussed
>> to the maximum in subjects like Efficient Algorithms, Special Problem Fields
>> of Operating System Design and Fundamentals of DBMS Design (eg. AtomicityCID
>> principle).
>> And such fundamental points are not (needed to be) discussed here.
>>
>> Furthermore, due to the competence it is possible for FS gurus like Ted to
>> estimate that the additional steps have to be done by several functions of
>> an FS, which implies performance loss. And because elementary FS functions
>> are involved the performance loss could be and in the past have been
>> significant, though in nearly all cases I have seen the reason was a very
>> bad implementation. The only exception so far is the Reiser4 FS: All of its
>> file operations are atomic, but still to a little cost of performance in the
>> most cases and the need of a repacker in some few cases which show a
>> significant loss of performance.
> So making all ops atomic can be done at a little performance hit, but
> implementing one specific op costs a huge performance hit? That
> doesn't make sense and seems to indicate those that say otherwise
> aren't right.

No, not in all cases, as it was explained (read the seocnd paragraph again).
And also, Reiser4 FS does no standard journaling to achieve this, and in 
this way had to change everything of the FS (read about the design 
concepts of the different FSs).

>> And the advice to use a well-known DBMS is simply based on the knowledge
>> that it has all the needed functionality already implemented in a highly
>> performant way, and on the knowledge that such a solution is used oftenly
>> for comparable use cases due to the cost vs. benefit ratio.
>> To take a look at the Reiser4 FS could also help.
> I don't think storing all my conf files, executables, libraries etc in
> a DBMS is a good idea...

read the whole both threads started by you again

> 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