On Sun, Oct 12, 2014 at 02:00:18PM -0500, BillStuff wrote: > On 10/12/2014 09:07 AM, Brian Foster wrote: > >On Sat, Oct 11, 2014 at 01:59:27PM -0500, BillStuff wrote: > >>Hi, > >> > >>I'm running 3.14.21, and got these traces in dmesg; they appear to be from > >>xfs: > >> > >>[56180.816526] ------------[ cut here ]------------ > >>[56180.816550] WARNING: CPU: 5 PID: 67 at fs/xfs/xfs_aops.c:1172 > > > > if (WARN_ON(delalloc)) > > return 0; > > > >So this generally looks like stale delalloc blocks on a page that is > >reclaimed/invalidated or otherwise expected to be clean. We've been > >seeing this a lot over the past few kernel releases and there have been > >a variety of fixes in error paths and such so it's hard to say precisely > >what might be causing this. Some examples: > > > >aad3f375 xfs: xfs_vm_write_end truncates too much on failure > >72ab70a1 xfs: write failure beyond EOF truncates too much data > >4ab9ed57 xfs: kill buffers over failed write ranges properly > > > >It looks like those are in the stable tree as of 3.15, so you could give > >that a try and see if it helps. Otherwise, can you post xfs_info for the > >filesytem? Do you have particular workloads or sequences of operations > >that tend to reproduce this? > > > >Brian > > > Thanks Brian, > > I'll try out those fixes. > It might be better to move to a more recent stable kernel if you can, as there could have been other fixes that I've missed. > The filesystem is home theater recordings on a 6 disk raid5 array: > > meta-data=/dev/md3 isize=256 agcount=81, agsize=15237264 > blks > = sectsz=4096 attr=2 > data = bsize=4096 blocks=1218981920, imaxpct=5 > = sunit=16 swidth=80 blks > naming =version 2 bsize=4096 ascii-ci=0 > log =internal bsize=4096 blocks=32768, version=2 > = sectsz=4096 sunit=1 blks, lazy-count=0 > realtime =none extsz=131072 blocks=0, rtextents=0 > > I believe it was just starting a recording when I got this message. > So creation of a new file? I guess that could mean reclaim of an old page to free up memory or something of that sort had detected it. If so, the problem could have originated any time in the past. Brian > -Bill > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
