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

From: Stan Hoeppner <stan@hardwarefreak.com>
To: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: xfs@oss.sgi.com
Subject: Re: Corruption of root fs during git bisect of drm system hang
Date: Thu, 11 Jul 2013 18:01:22 -0500	[thread overview]
Message-ID: <51DF3942.4050506@hardwarefreak.com> (raw)
In-Reply-To: <20130711204033.GA355@x4>

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.

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs