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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
