[Top] [All Lists]

Re: dmesg error in xfs_aops.c on kernel 3.14.21

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: dmesg error in xfs_aops.c on kernel 3.14.21
From: BillStuff <billstuff2001@xxxxxxxxxxxxx>
Date: Sun, 12 Oct 2014 14:00:18 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1413140420; bh=s7sIVcavJ3/FHimPS8CaVpCyvEoJN6wFjKyFgKaxIE8=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=fHQtptUF47UJSYQFMxFL3nMUEJuAlldGu7TqaKhBZb+ABsZuF+M2W9ibIVklzCJD/vPA0aifv61aeV9XefBohQWzeNU90zo7cl2QTNJB+6id8HnhFsYDoKHxdkvN+okglkDolVGTeHZ58u2k8nLi+X3tG208KXkn+eGn7sQiDuI=
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1413140419; bh=s7sIVcavJ3/FHimPS8CaVpCyvEoJN6wFjKyFgKaxIE8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=5k6LET/gU0CeW3aNbpBQJnUd/o71mN7P5pBF0rBpKF2sstSA/QkLpHivC9wOeyK2HM4S+YaNqOJf2pilP036cA7uSm1yqyH9j3l/ZiIoox9t4p00PqC+JBv0Q8bYU+P8j2zc38md51HgnLoiH9PGNmuQ1cHWE+iwXyI6DwBSBfQ=
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; b=a/6kP4Jfl7/OZbU5y+ZCfNusTFjKn40LZHedCLegb6K/ShelwG/C3l8P0vIN8/QY016m02Z1XV/DFXqXwFL2bEaNxTqzoqTn0SvZoiQqsRAA2503qXFnhY6BAtvGTqZkDQO//klS7dcn5ystUwmCLp9CjS0rTv+W1AmHohGWDZs=;
In-reply-to: <20141012140704.GA35667@xxxxxxxxxxxxxxx>
References: <54397E0F.2050700@xxxxxxxxxxxxx> <20141012140704.GA35667@xxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
On 10/12/2014 09:07 AM, Brian Foster wrote:
On Sat, Oct 11, 2014 at 01:59:27PM -0500, BillStuff wrote:

I'm running 3.14.21, and got these traces in dmesg; they appear to be from

[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?


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.


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