Re: Atomic non-durable file write API

[Christian Stroetmann <stroetmann@ontolinux.com>]

On 24.12.2010 01:48, Ted Ts'o wrote:
> On Fri, Dec 24, 2010 at 01:30:05AM +0100, Christian Stroetmann wrote:
>>> 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
> Fine, if you use sqlite, then you're not playing games with replacing
> file contents using rename, and you're using fsync.  No problems.
>
> Unfortunately, there are lots of incompetently written applications
> out there.  One of them, I can't remember whether it was using GNOME
> or KDE libraries (I blocked it out, it was so horrifying), used the
> standard GNOME and/or KDE libraries to implement a windows-style
> registry, with one small file for each variable.  Unfortunately, there
> was a bug in the GNOME or KDE library where it screwed up the dirty
> flag test, and would rewrite and replace *every* *single* *small*
> *file* when the application exited.
I really do know what you want to say, despite that this example is 
based on a bug in another system than the FS. But there will be other 
examples, for sure.
> Sure, if you need to write the new file, fsync it, and then rename it
> in place, for every single of the several hundred state files, life is
> going to suck.  But that's not the file system's fault, even though
> people tried to blame this on the file system.
>
> The problem is an incompetent userspace programmer that tried to use
> small files and file system calls when they should have used a
> database.
Yes, indeed.
>
>
> 						- Ted
> --

Thank you very much vor your time and explanations.


Christian Stroetmann