xfs
[Top] [All Lists]

Re: xfs_getbmap assert

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: xfs_getbmap assert
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 8 Nov 2011 07:15:05 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20111107103037.GA16213@xxxxxxxxxxxxx>
References: <20111107103037.GA16213@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Nov 07, 2011 at 05:30:37AM -0500, Christoph Hellwig wrote:
> With Dmitris fsstress updates I can hit the following assert fairly
> regularly:
> 
> [11904.943956] XFS: Assertion failed: ((iflags & BMV_IF_DELALLOC) != 0) ||
> (map[i].br_startblock != DELAYSTARTBLOCK), file:
> /home/hch/work/linux-2.6/fs/xfs/xfs_bmap.c, line: 5604
> 
> which means we get an delalloc extent back from FIEMAP/GETBMAP despite
> asking for a flush beforehand.  While we hold the iolock over the call
> and thus exclude new buffered writers from appearing that doesn't
> prevent shared writeable mmaps from creating new delalloc extents.

Possibly. However, we might actually be tripping over speculative
delalloc regions beyond EOF - flushing will not convert those at
all. There's already a comment earlier on like this:

        /*
         * even after flushing the inode, there can still be delalloc
         * blocks on the inode beyond EOF due to speculative
         * preallocation. These are not removed until the release
         * function is called or the inode is inactivated. Hence we
         * cannot assert here that ip->i_delayed_blks == 0.
         */

Can you see if that is the case that is being triggered?

> I don't think this actually is a real issue, and a workaround would
> be extremly hard.  For now I've just remove the assert in my tree:

Probably the right thing to do, anyway.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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