[Top] [All Lists]

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

To: Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx>
Subject: Re: Corruption of root fs during git bisect of drm system hang
From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Thu, 11 Jul 2013 18:01:22 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130711204033.GA355@x4>
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> <20130711204033.GA355@x4>
Reply-to: stan@xxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
On 7/11/2013 3:40 PM, Markus Trippelsdorf wrote:
> 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?

Apparently you missed the O_PONIES debate some 4 years ago.  Take a
guess as to what happens to XFS performance if it is modified to "fix"
this app dev broken file on crash problem.  Hint:  a bunch of previously
asynchronous operations must now to be forced to be synchronous.


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