xfs
[Top] [All Lists]

Re: REVIEW: Fix for incore extent corruption.

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: REVIEW: Fix for incore extent corruption.
From: Lachlan McIlroy <lachlan@xxxxxxx>
Date: Fri, 19 Sep 2008 10:55:16 +1000
Cc: Russell Cattelan <cattelan@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <59243.131.252.241.230.1221762601.squirrel@sandeen.net>
References: <48D19A83.4040608@thebarn.com> <48D1CD46.4010104@sgi.com> <48D1DCD5.7040502@thebarn.com> <48D218AE.9090400@sgi.com> <59243.131.252.241.230.1221762601.squirrel@sandeen.net>
Reply-to: lachlan@xxxxxxx
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 2.0.0.16 (X11/20080707)
Eric Sandeen wrote:
Lachlan McIlroy wrote:
Russell, this fixes xfs_iext_irec_compact_full().  If we don't move
all the records from the next page into the current page then we need
to update the er_extoff of the modified page as we move the remaining
extents up.  Would you mind giving it a go?

--- a/fs/xfs/xfs_inode.c        2008-09-18 18:48:46.000000000 +1000
+++ b/fs/xfs/xfs_inode.c        2008-09-18 18:57:18.000000000 +1000
@@ -4623,6 +4623,7 @@ xfs_iext_irec_compact_full(
                                        (XFS_LINEAR_EXTS -
                                                erp_next->er_extcount) *
                                        sizeof(xfs_bmbt_rec_t));
+                               erp_next->er_extoff += ext_diff;
                        }
                }

Lachlan, I concur. I spent way too long last night looking at this and arrived at the same conclusion about the root cause of the problem, but didn't hae *quite* the right solution. I blame it on 2am ;) Your fix looks right.

(though I'd probably move the erp_next changes into the else clause? Otherwise you're changing it then freeing it.)
I don't understand what you mean by that.  Could you elaborate?


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