xfs
[Top] [All Lists]

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

To: Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx>
Subject: Re: [Bisected] Corruption of root fs during git bisect of drm system hang
From: Ben Myers <bpm@xxxxxxx>
Date: Fri, 19 Jul 2013 14:13:31 -0500
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
In-reply-to: <20130719163220.GA363@x4>
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>
User-agent: Mutt/1.5.20 (2009-06-14)
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.

Thanks much,
        Ben

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