From: Olaf van der Spek Subject: Re: Atomic non-durable file write API Date: Wed, 29 Dec 2010 16:41:45 +0100 Message-ID: References: <20101224095105.GG12763@thunk.org> <20101226221016.GF2595@thunk.org> <4D18B106.4010308@ontolinux.com> <4D18E94C.3080908@ontolinux.com> <20101229075928.6bdafb08@notabene.brown> <20101229093158.2bfed8ca@notabene.brown> <4D1B542B.9030400@ontolinux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: linux-fsdevel , linux-ext4 , "Ted Ts'o" , Neil Brown , Nick Piggin To: Christian Stroetmann Return-path: In-Reply-To: <4D1B542B.9030400@ontolinux.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org On Wed, Dec 29, 2010 at 4:30 PM, Christian Stroetmann 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? > 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. > 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. > 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... Olaf