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
|