xfs
[Top] [All Lists]

Re: Corruption of root fs during git bisect of drm system hang

To: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Subject: Re: Corruption of root fs during git bisect of drm system hang
From: Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx>
Date: Thu, 11 Jul 2013 22:40:33 +0200
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=simple; d=mail.ud10.udmedia.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=beta; bh=v6zRFQrHDD/CbhHE3/2Rqc7OVF 24NT1YQzsmzROsltY=; b=BjAHxOJgpetwQd6lC5UgsYUEUdyL7btaOoQ9NFQADW PVrLbv44LpfGZJxW/j6AaiaIjX/sI5NZGAoVM2VjmEraREk4zT+d1RvquLH7qBhx 9IBdy+I54GmHAjjYYIFKd3dLGYU5iNltk5COQ16ZdcIVf8Y6Z0MrjW3f7+aWya+g Y=
In-reply-to: <51DF1463.1070603@xxxxxxxxxxxxxxxxx>
References: <20130710090634.GA356@x4> <20130711003122.GR3438@dastard> <20130711033621.GB362@x4> <20130711035827.GA3438@dastard> <51DE30BC.1050905@xxxxxxxxxxxxxxxxx> <20130711090755.GA363@x4> <20130711112826.GA363@x4> <51DF1463.1070603@xxxxxxxxxxxxxxxxx>
On 2013.07.11 at 15:24 -0500, Stan Hoeppner wrote:
> On 7/11/2013 6:28 AM, Markus Trippelsdorf wrote:
> ...
> >> Looking at the source:
> >> http://api.kde.org/4.10-api/kdelibs-apidocs/kdecore/html/ksavefile_8cpp_source.html#l00219
> >> it appears that one can set an environment variable KDE_EXTRA_FSYNC to
> >> address this issue.
> >>
> >> However in my case it doesn't help. Even with KDE_EXTRA_FSYNC=1 I still
> >> loose my KDE settings in case of a crash. So the whole fsync thing might
> >> be a red herring.
> > 
> > It turned out that the KDE_EXTRA_FSYNC variable doesn't affect KDE
> > config file handling at all.
> > So I've added an fsync in kconfigini.cpp (KConfigIniBackend::writeConfig)
> > and now I don't loose my settings anymore during kernel crash testing.
> > 
> > That is until xfs eats my KDE config files (kwinrulesr in this case):
> 
> Adding fsync in kconfigini.cpp apparently doesn't force fsync for all
> KDE file operations.  You also have some Open Office files getting hosed
> due to lack of fsync.  XFS is not the cause of these problems.
>
> The problem is that all of this desktop code was developed atop EXT3
> which flushed to disk every 5 seconds.  This made programmers sloppy as
> they didn't have to fsync to make sure data hit disk.  This problem has
> been covered extensively by many, including Eric in other posts on his
> blog.  There's a really simple way to test this:  mount with sync.
> Report results after the next crash.  If no files are corrupted then
> you've verified the problem lay squarely on the shoulders of these
> desktop developers who have abdicated their responsibility to make sure
> their file changes hit the disk, instead of relying on a broken
> filesystem do it for them.
> 
> Worth noting, using EXT4 without the EXT3 flush emulation enabled will
> yield similar file corruption upon a crash.

I'm not so sure. Of course a journaled filesystem is not a database
replacement, but wouldn't it be easier to address this issue in xfs
directly instead of hoping in vain that application developers will
fix their code someday?

-- 
Markus

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