LWN article: ext4 and data loss

[Eric Sandeen]

Martin Steigerwald wrote:
> Am Donnerstag 12 März 2009 schrieb Eric Sandeen:
...

>> Filesystems can hack around some heuristics to try to make unsafe apps
>> safer, but in the end, it's the app's job to make sure a buffered write
>> hits permanent storage when it matters.
> 
> Hmmm, okay. So here is:
> 
> http://bugs.kde.org/187172
> 
> Feel free to add there. You'd need a bugzilla login tough.
> 
> Ciao,

Perhaps you can try this and add info if you like.

There is an environment variable KDE_EXTRA_FSYNC, put in with this
changelog:

Do not paranoidly sync every time, it causes I/O performance problems
for some users. People who still want it for whatever reason like using
XFS can set $KDE_EXTRA_FSYNC to 1."

This is not "extra" - it is necessary if you actually want the data to
be on-disk.

See also: http://lists.kde.org/?l=kde-devel&m=120880682813170&w=2

(note however that xfs is _not_ "zeroing just to be sure...")

http://api.kde.org/4.x-api/kdelibs-apidocs/kde3support/html/k3tempfile_8cpp-source.html

 bool
 K3TempFile::sync()
    int result = 0;

    if (mStream)
    {
       do {
          result = fflush(mStream); // We need to flush first otherwise
fsync may not have our data
       }
       while ((result == -1) && (errno == EINTR));

       if (result)
       {
          kWarning() << "K3TempFile: Error trying to flush " << mTmpName
 " << strerror(errno);
          mError = errno;
       }
    }

    if (mFd >= 0)
    {
       if( qgetenv( "KDE_EXTRA_FSYNC" ) == "1" )
       {
          result = FDATASYNC(mFd);
          if (result)
          {
             kWarning() << "K3TempFile: Error trying to sync " <<
mTmpName << ": " << strerror(errno);
             mError = errno;
          }
       }
    }

    return (mError == 0);
 }

So somebody knew it was the right thing to do, but then turned it off,
probably because of ext3's painful behavior on fsync (see also: firefox
"bug" from a while ago)

what's interesting is that the sync() method isn't automatically called
from the other methods, near as I can tell, so it's up to the api user
to invoke it; and even then it only does fflush() not fsync() by
default, which doesn't actually push things to disk.

I'd suggest turning on this KDE_EXTRA_FSYNC and see how things go from
there on.

Although, the API refs say that this is deprecated in favor of
KTemporaryFile, and I find no reference whatsoever to "sync" of any kind
in ktemporaryfile.cpp.

-Eric