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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
