[Top] [All Lists]

Re: LWN article: ext4 and data loss

To: Martin Steigerwald <Martin@xxxxxxxxxxxx>
Subject: Re: LWN article: ext4 and data loss
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Sat, 14 Mar 2009 15:02:00 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <200903142042.51574.Martin@xxxxxxxxxxxx>
References: <200903121239.35442@xxxxxx> <200903121514.12732.Martin@xxxxxxxxxxxx> <49B92423.4020708@xxxxxxxxxxx> (sfid-20090312_171308_416656_6FF6859A) <200903142042.51574.Martin@xxxxxxxxxxxx>
User-agent: Thunderbird (Macintosh/20081209)
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

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...")


    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.


<Prev in Thread] Current Thread [Next in Thread>