xfs: fix log recovery transaction item reordering
authorDave Chinner <dchinner@redhat.com>
Wed, 5 Jun 2013 02:09:07 +0000 (12:09 +1000)
committerBen Myers <bpm@sgi.com>
Thu, 6 Jun 2013 15:51:07 +0000 (10:51 -0500)
commit75406170751b4de88a01f73dda56efa617ddd5d7
treeb9eac9caa2d9dc318e0ac71cd3bf8f9556db0d5f
parentea929536a43226a01d1a73ac8b14d52e81163bd4
xfs: fix log recovery transaction item reordering

There are several constraints that inode allocation and unlink
logging impose on log recovery. These all stem from the fact that
inode alloc/unlink are logged in buffers, but all other inode
changes are logged in inode items. Hence there are ordering
constraints that recovery must follow to ensure the correct result
occurs.

As it turns out, this ordering has been working mostly by chance
than good management. The existing code moves all buffers except
cancelled buffers to the head of the list, and everything else to
the tail of the list. The problem with this is that is interleaves
inode items with the buffer cancellation items, and hence whether
the inode item in an cancelled buffer gets replayed is essentially
left to chance.

Further, this ordering causes problems for log recovery when inode
CRCs are enabled. It typically replays the inode unlink buffer long before
it replays the inode core changes, and so the CRC recorded in an
unlink buffer is going to be invalid and hence any attempt to
validate the inode in the buffer is going to fail. Hence we really
need to enforce the ordering that the inode alloc/unlink code has
expected log recovery to have since inode chunk de-allocation was
introduced back in 2003...

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
(cherry picked from commit a775ad778073d55744ed6709ccede36310638911)
fs/xfs/xfs_log_recover.c