dmesg error in xfs_aops.c on kernel 3.14.21

[BillStuff]

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