[Top] [All Lists]

Re: [PATCH 9/9] xfs: inode unlinked list needs to recalculate the inode

To: xfs@xxxxxxxxxxx
Subject: Re: [PATCH 9/9] xfs: inode unlinked list needs to recalculate the inode CRC
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 28 May 2013 21:51:50 +1000
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1369636707-15150-10-git-send-email-david@xxxxxxxxxxxxx>
References: <1369636707-15150-1-git-send-email-david@xxxxxxxxxxxxx> <1369636707-15150-10-git-send-email-david@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, May 27, 2013 at 04:38:27PM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@xxxxxxxxxx>
> The inode unlinked list manipulations operate directly on the inode
> buffer, and so bypass the inode CRC calculation mechanisms. Hence an
> inode on the unlinked list has an invalid CRC. Fix this by
> recalculating the CRC whenever we modify an unlinked list pointer in
> an inode. This is trivial to do, and the new CRC gets logged with
> the inode core so on replay of the unlinked list operations this
> will be updated as expected and remain consistent.
> Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>

I need to rework this fix.

The fact that it actually requires log recovery to follow it's
documented recovery ordering constraints has exposed a bug in those
the log recovery transaction item re-ordering code. The bug has
been there since inode chunk deletion was introduced in 2003.

It has also shown up that there is no guarantee that the on-disk
inode in the buffer is actually uptodate, so recording the CRC in
the transaction for recovery is the wrong thing to do because it may
be different to what recovery ends up with after reordering all the
modifications. So the correct thing to do is to have recovery
recalculate the on-disk inode CRC are modifying the unlinked list...

So, there's 2-3 patches that need to replace this one....

Thank xfs/121 and the icreate patch set for finding this mess.


Dave Chinner

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