From: Mark Tinguely <tinguely@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 1/4] xfs: fix log recovery transaction item reordering
Date: Wed, 05 Jun 2013 08:13:27 -0500 [thread overview]
Message-ID: <51AF3977.1030104@sgi.com> (raw)
In-Reply-To: <1370398150-12084-2-git-send-email-david@fromorbit.com>
On 06/04/13 21:09, Dave Chinner wrote:
> From: Dave Chinner<dchinner@redhat.com>
>
> 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>
Looks good.
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-06-05 13:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-05 2:09 [PATCH 0/4] xfs: outstanding fixes for 3.10 Dave Chinner
2013-06-05 2:09 ` [PATCH 1/4] xfs: fix log recovery transaction item reordering Dave Chinner
2013-06-05 13:13 ` Mark Tinguely [this message]
2013-06-05 2:09 ` [PATCH 2/4] xfs: inode unlinked list needs to recalculate the inode CRC Dave Chinner
2013-06-05 14:43 ` Mark Tinguely
2013-06-05 2:09 ` [PATCH 3/4] xfs: disable noattr2/attr2 mount options for CRC enabled filesystems Dave Chinner
2013-06-05 2:09 ` [PATCH 4/4] xfs: increase number of ACL entries for V5 superblocks Dave Chinner
2013-06-05 13:26 ` Mark Tinguely
2013-06-05 13:38 ` Mark Tinguely
2013-06-05 16:44 ` [PATCH 0/4] xfs: outstanding fixes for 3.10 Ben Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51AF3977.1030104@sgi.com \
--to=tinguely@sgi.com \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.