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....