xfs
[Top] [All Lists]

Re: dmesg error in xfs_aops.c on kernel 3.14.21

To: BillStuff <billstuff2001@xxxxxxxxxxxxx>
Subject: Re: dmesg error in xfs_aops.c on kernel 3.14.21
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Mon, 13 Oct 2014 07:21:05 -0400
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <543ACFC2.2090308@xxxxxxxxxxxxx>
References: <54397E0F.2050700@xxxxxxxxxxxxx> <20141012140704.GA35667@xxxxxxxxxxxxxxx> <543ACFC2.2090308@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.23 (2014-03-12)
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

<Prev in Thread] Current Thread [Next in Thread>