From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Stroetmann Subject: Re: Atomic non-durable file write API Date: Fri, 24 Dec 2010 01:30:05 +0100 Message-ID: <4D13E98D.8070105@ontolinux.com> References: <4D0A7278.3080506@gmail.com> <1292710543.17128.14.camel@nayuki> <20101224085126.2a7ff187@notabene.brown> <20101223222206.GD12763@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel , Neil Brown , Olaf van der Spek To: Ted Ts'o Return-path: Received: from moutng.kundenserver.de ([212.227.17.10]:50274 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752245Ab0LXAaN (ORCPT ); Thu, 23 Dec 2010 19:30:13 -0500 In-Reply-To: <20101223222206.GD12763@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 23.12.2010 23:22, Ted Ts'o wrote: > On Fri, Dec 24, 2010 at 08:51:26AM +1100, Neil Brown wrote: >> You are asking for something that doesn't exist, which is why no-one can tell >> you want the answer is. > Basically, file systems are not databases, and databases are not file > systems. There seems to be an unfortunate tendency for application > programmers to want to use file systems as databases, and they suffer > as a result. wrong, no suffer, quite contrary, take an approach like done with sqlite [...] > You may *say* that you don't care which version of the file you get > after a rename, but only that one or the other is valid, but what if > some other program reads from the file, gets the second file, and > sends out a network message saying the rename was successful, but then > a crash happens and the rename is undone? There's a reason why > databases block reads of a modified row until the transaction is > completed or rolled back. where is the suffer then to use database semantics? [...] > Or use a real database, and don't try to assume you will get database > semantics when you try to write to multiple small files. wrong, do Atomicity + CID [...] > But for the crazy kids who want to write several hundred small files > when an GNOME or KDE application exits (one file for the X coordinate > for the window, another file for the Y coordinate, another file for > the height of the window, another file for the width of the window, > etc....) --- cut it out. That way just lies insanity; use something > like sqlite instead and batch all of your updates into a single atomic > update. what now? see above! where is the unfortunate tendency and suffer? > Or don't use crappy proprietary drivers that will crash your > system at arbitrary (and commonplace) times. > > - Ted Christian Stroetmann