xfs
[Top] [All Lists]

Re: xfs bug in 2.6.26-rc9

To: Mikael Abrahamsson <swmike@xxxxxxxxx>
Subject: Re: xfs bug in 2.6.26-rc9
From: Lachlan McIlroy <lachlan@xxxxxxx>
Date: Mon, 14 Jul 2008 17:34:51 +1000
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <alpine.DEB.1.10.0807111215040.30192@xxxxxxxxxxxxxxxx>
References: <alpine.DEB.1.10.0807110939520.30192@xxxxxxxxxxxxxxxx> <20080711084248.GU29319@disturbed> <alpine.DEB.1.10.0807111215040.30192@xxxxxxxxxxxxxxxx>
Reply-to: lachlan@xxxxxxx
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 2.0.0.14 (X11/20080421)
Mikael Abrahamsson wrote:
On Fri, 11 Jul 2008, Dave Chinner wrote:

That aside, what was the assert failure reported prior to the oops? i.e. paste the lines in the log before the ---[ cut here ]--- line? One of them will start with 'Assertion failed:', I think....

These ones?

Jul 8 04:44:56 via kernel: [554197.888008] Assertion failed: whichfork == XFS_ATTR_FORK || ip->i_delayed_blks == 0, file: fs/xfs/xfs_bmap.c, line: 5879 Jul 9 03:25:21 via kernel: [42940.748007] Assertion failed: whichfork == XFS_ATTR_FORK || ip->i_delayed_blks == 0, file: fs/xfs/xfs_bmap.c, line: 5879

        xfs_ilock(ip, XFS_IOLOCK_SHARED);

        if (whichfork == XFS_DATA_FORK &&
                (ip->i_delayed_blks || ip->i_size > ip->i_d.di_size)) {
                /* xfs_fsize_t last_byte = xfs_file_last_byte(ip); */
                error = xfs_flush_pages(ip, (xfs_off_t)0,
                                               -1, 0, FI_REMAPF);
                if (error) {
                        xfs_iunlock(ip, XFS_IOLOCK_SHARED);
                return error;
                }
        }

        ASSERT(whichfork == XFS_ATTR_FORK || ip->i_delayed_blks == 0);

This is a race between xfs_fsr and a mmap write.  xfs_fsr acquires the
iolock and then flushes the file and because it has the iolock it doesn't
expect any new delayed allocations to occur.  A mmap write can allocate
delayed allocations without acquiring the iolock so is able to get in
after the flush but before the ASSERT.


I'll happily rebuild the kernel without the debug option and do xfs_check to weed out any possible logical problem with the volume, if you don't need any further information from the current state of my volume.

I should also say that this assert failue happened two nights in a row so I guess it's fairly reproducible (didn't happen on the 10th, and today, the 11th it seems to have panic:ed around 03:30 (I start the defragmentation via cron at 03:00) which I think is related.



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