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

From: Dave Chinner <david@fromorbit.com>
To: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Stan Hoeppner <stan@hardwarefreak.com>, xfs@oss.sgi.com
Subject: Re: Corruption of root fs during git bisect of drm system hang
Date: Fri, 12 Jul 2013 12:17:37 +1000	[thread overview]
Message-ID: <20130712021737.GA5228@dastard> (raw)
In-Reply-To: <20130711090755.GA363@x4>

On Thu, Jul 11, 2013 at 11:07:55AM +0200, Markus Trippelsdorf wrote:
> On 2013.07.10 at 23:12 -0500, Stan Hoeppner wrote:
> > On 7/10/2013 10:58 PM, Dave Chinner wrote:
> > > On Thu, Jul 11, 2013 at 05:36:21AM +0200, Markus Trippelsdorf wrote:
> > 
> > >> I was loosing my KDE settings bit by bit with every reboot during the
> > >> bisection. First my window-rules disappeared, then my desktop background
> > >> changed to default, then my taskbar moved from top to the bottom, etc.
> > >> In the end I had to restore all my .files from backup. 
> > > 
> > > That's not filesystem corruption. That sounds more like someone not
> > > using fsync in the apropriate place when overwriting a file....
> > 
> > From Sandeen's blog, March 2009:
> > 
> > "I dunno how to resolve this right now.  I talked to some nice KDE folks
> > on irc; they basically want atomic writes, either you get your old file
> > or your new file post-crash; and tempfile/sync/rename does this – but
> > the fsync hurts on 78% of the Linux filesystems out there.  So their
> > KSaveFile class doesn’t fsync.  So what to do, what to do.."
> > 
> > That's 4 years ago.  Is it possible the KDE devs are still not using
> > fsync?  Sure seems likely given Markus' problem.
> 
> 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.
> 
> What's more this time I endend up with undeletable files in /tmp (for
> example .X0-lock) after the crash:
> 
> (/dev/sdb was mounted and unmounted normally before I ran xfs_repair)
> 
> t@ubunt:~# xfs_repair /dev/sdb
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
>         - zero log...
>         - scan filesystem freespace and inode maps...
> agi unlinked bucket 0 is 683435008 in ag 2 (inode=4978402304)
> agi unlinked bucket 1 is 683435009 in ag 2 (inode=4978402305)
>         - found root inode chunk

Again, these are signs that log recovery has not completed
successfully or that for some reason it thought the log was clean.
Can you please post the dmesg output after the crash when you go
through the mount/unmount process before you run xfs_repair?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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