[Top] [All Lists]

Re: [PATCH V2] Always reset btree cursor after an insert

To: Lachlan McIlroy <lachlan@xxxxxxx>
Subject: Re: [PATCH V2] Always reset btree cursor after an insert
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 20 Jun 2008 13:37:10 +1000
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <485B0B04.80808@xxxxxxx>
Mail-followup-to: Lachlan McIlroy <lachlan@xxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
References: <4859F9EB.5050505@xxxxxxx> <20080619083544.GA19606@xxxxxxxxxxxxx> <485B0B04.80808@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.17+20080114 (2008-01-14)
On Fri, Jun 20, 2008 at 11:42:28AM +1000, Lachlan McIlroy wrote:
> Christoph Hellwig wrote:
>> On Thu, Jun 19, 2008 at 04:17:15PM +1000, Lachlan McIlroy wrote:
>>> After a btree insert operation a cursor can be invalid due to block
>>> splits and a maybe a new root block.  We reset the cursor in
>>> xfs_bmbt_insert() in the cases where we think we need to but it
>>> isn't enough as we still see assertions.  Just do what we do elsewhere
>>> and reset the cursor unconditionally.  Version 2 adds
>>> XFS_WANT_CORRUPTED_GOTO checks throughout xfs_bmap.c and removes the
>>> fix to revalidate the original cursor in xfs_bmbt_insert().
>> Can you commit the XFS_WANT_CORRUPTED_GOTO checks as a separate patch
>> before the cursor reset?  ACK from me for those hunks.
> Yeah, no problem, thanks.

The rest of it looks ok as well, Lachlan.


Dave Chinner

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