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