xfs
[Top] [All Lists]

Re: [Bisected] Corruption of root fs during git bisect of drm system han

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [Bisected] Corruption of root fs during git bisect of drm system hang
From: Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx>
Date: Fri, 19 Jul 2013 21:56:28 +0200
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, Stefan Ring <stefanrin@xxxxxxxxx>, Mark Tinguely <tinguely@xxxxxxx>, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>, Linux fs XFS <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=m39CuFvlV2+tQLz/bktbOSxc3O ZbJhJ8pydsfcF9WOI=; b=VjhQ2JruYey55P/8cSqGvFsoKSvqN79+AEg91WdNLb BB+GStSifK0KaIlGmkoA/FGJoh1iNRC1yxNFhj+WU/DzbMIluWq7OVLmqbvUQX+a 8Ta6V3s1SKYnAWdaCrsCrPhlf7R8BAKvwHcs2C6hNAYHi+qF9INvAiKmJoRrqgDX s=
In-reply-to: <20130719191331.GG3572@xxxxxxx>
References: <20130713090523.GA362@x4> <20130712070721.GA359@x4> <20130715022841.GH5228@dastard> <20130715064734.GA361@x4> <20130719122235.GA360@x4> <CAAxjCExBi-4Qgf6-=MBzdkzBmMtu=GTURu46DoD2CzpnF2dinw@xxxxxxxxxxxxxx> <20130719125149.GB360@x4> <51E9630A.3070201@xxxxxxxxxxx> <20130719163220.GA363@x4> <20130719191331.GG3572@xxxxxxx>
On 2013.07.19 at 14:13 -0500, Ben Myers wrote:
> Hey Markus,
> 
> On Fri, Jul 19, 2013 at 06:32:20PM +0200, Markus Trippelsdorf wrote:
> > On 2013.07.19 at 11:02 -0500, Eric Sandeen wrote:
> > > > Unfortunately it turned out that in this case there is filesystem
> > > > corruption. (Fortunately this normally happens only very rarely on rc1
> > > > kernels).
> > > 
> > > Corruption is when you get back data that you did not write,
> > > or metadata which is inconsistent or unreadable even after a proper
> > > log replay.
> > > 
> > > Corruption is _not_ unsynced, buffered data that was lost on a
> > > crash or poweroff.
> > > 
> > > But I might not have followed the thread properly, and I might
> > > misunderstand your situation.
> > > 
> > > When you experience this lost file [data] scenario, was it after an
> > > orderly reboot, or after a crash and/or system reset?
> > 
> > To reproduce this issue simply boot into your desktop and then hit
> > sysrq-c and reboot. After log replay without error messages, the
> > filesystem is in an inconsistent state and many small config files are
> > lost. There are also undeletable files. You need to run xfs_repair
> > manually to bring the filesystem back to normal.
> > 
> > When cca9f93a52d is reverted, you don't loose your config files and the
> > filesystem is OK after log replay. xfs_repair reports no issues at all.
> 
> I'm a bit late to the party, but I wanted to give this a try.
> 
> On the machine I tried, I was not able to reproduce any corruption with a
> 
> echo b > /proc/sysrq-trigger
> 
> xfs_repair -n found no problems at all.  I'll try it on a few more.
> 
> Could you post some of your latest xfs_repair output?  And, have you been able
> to reproduce this on more than one machine?  I may have missed that detail
> earlier in the thread.

I didn't save the xfs_repair output on every run. See the examples that
I've posted in this thread before.
And the issue always happens on the same machine.

-- 
Markus

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