On Mon, Oct 29, 2012 at 10:48:02AM +1100, Dave Chinner wrote: > On Sat, Oct 27, 2012 at 12:05:34AM +0200, Yann Dupont wrote: > > Le 26/10/2012 12:03, Yann Dupont a écrit : > > >Le 25/10/2012 23:10, Dave Chinner a écrit : > > > > > >I'll try now to reproduce this kind of behaviour on a verry little > > >volume (10 GB for exemple) so I can confirm or inform the given > > >scenario . > > > > > > > This is reproductible. Here is how to do it : > > > > - Started a 3.6.2 kernel. > > > > - I created a fresh lvm volume on localdisk of 20 GB. > > Can you reproduce the problem without LVM? > > > - mkfs.xfs on it, with default options > > - mounted with default options > > - launch something that hammers this volume. I launched compilebench > > 0.6 on it > > - wait some time to fill memory,buffers, and be sure your disks are > > really busy. I waited some minutes after the initial 30 kernel > > unpacking in compilebench > > - hard reset the server (I'm using the Idrac of the server to > > generate a power cycle) > > - After some try, I finally had the impossibility to mount the xfs > > volume, with the error reported in previous mails. So far this is > > normal . > > So it doesn't happen every time, and it may be power cycle related. > What is your "local disk"? I can't reproduce this with a similar setup but using KVM (i.e. killing the VM instead of power cycling) or forcing a shutdown of the filesystem without flushing the log. The second case is very much the same as power cycling, but without the potential "power failure caused partial IOs to be written" problem. The only thing I can see in the logprint that I haven't seen so far in my testing is that your log print indicates a checkpoint that wraps the end of the log. I haven't yet hit that situation by chance, so I'll keep trying to see if that's the case that is causing the problem.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs