Re: Atomic non-durable file write API

[Christian Stroetmann <stroetmann@ontolinux.com>]

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