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

[Ben Myers <bpm@sgi.com>]

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

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