Re: Atomic non-durable file write API

[Ted Ts'o <tytso@mit.edu>]

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.

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. 

						- Ted