From: Liu Bo <bo.li.liu@oracle.com>
To: Jan Schmidt <list.btrfs@jan-o-sch.net>
Cc: chris.mason@fusionio.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/6] Btrfs: don't put removals from push_node_left into tree mod log twice
Date: Tue, 23 Oct 2012 23:23:35 +0800 [thread overview]
Message-ID: <5086B677.7050905@oracle.com> (raw)
In-Reply-To: <1351000527-24952-2-git-send-email-list.btrfs@jan-o-sch.net>
On 10/23/2012 09:55 PM, Jan Schmidt wrote:
> Independant of the check (push_items < src_items) tree_mod_log_eb_copy did
> log the removal of the old data entries from the source buffer. Therefore,
> we must not call tree_mod_log_eb_move if the check evaluates to true, as
> that would log the removal twice, finally resulting in (rewinded) buffers
> with wrong values for header_nritems.
>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Tested-by: Liu Bo <bo.li.liu@oracle.com>
thanks,
liubo
> Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
> ---
> fs/btrfs/ctree.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
> index b334362..44a7e25 100644
> --- a/fs/btrfs/ctree.c
> +++ b/fs/btrfs/ctree.c
> @@ -1225,6 +1225,8 @@ tree_mod_log_rewind(struct btrfs_fs_info *fs_info, struct extent_buffer *eb,
> free_extent_buffer(eb);
>
> __tree_mod_log_rewind(eb_rewin, time_seq, tm);
> + WARN_ON(btrfs_header_nritems(eb_rewin) >
> + BTRFS_NODEPTRS_PER_BLOCK(fs_info->fs_root));
>
> return eb_rewin;
> }
> @@ -1280,6 +1282,7 @@ get_old_root(struct btrfs_root *root, u64 time_seq)
> else
> WARN_ON(btrfs_header_level(eb) != 0);
> extent_buffer_get(eb);
> + WARN_ON(btrfs_header_nritems(eb) > BTRFS_NODEPTRS_PER_BLOCK(root));
>
> return eb;
> }
> @@ -2970,8 +2973,10 @@ static int push_node_left(struct btrfs_trans_handle *trans,
> push_items * sizeof(struct btrfs_key_ptr));
>
> if (push_items < src_nritems) {
> - tree_mod_log_eb_move(root->fs_info, src, 0, push_items,
> - src_nritems - push_items);
> + /*
> + * don't call tree_mod_log_eb_move here, key removal was already
> + * fully logged by tree_mod_log_eb_copy above.
> + */
> memmove_extent_buffer(src, btrfs_node_key_ptr_offset(0),
> btrfs_node_key_ptr_offset(push_items),
> (src_nritems - push_items) *
>
next prev parent reply other threads:[~2012-10-23 15:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-23 13:55 [PATCH 0/6] Btrfs: tree mod log fixes for 3.7-rc3 Jan Schmidt
2012-10-23 13:55 ` [PATCH 1/6] Btrfs: don't put removals from push_node_left into tree mod log twice Jan Schmidt
2012-10-23 15:23 ` Liu Bo [this message]
2012-10-23 13:55 ` [PATCH 2/6] Btrfs: fix a tree mod logging issue for root replacement operations Jan Schmidt
2012-10-23 15:28 ` Liu Bo
2012-10-23 15:51 ` Jan Schmidt
2012-10-23 13:55 ` [PATCH 3/6] Btrfs: tree mod log's old roots could still be part of the tree Jan Schmidt
2012-10-23 15:30 ` Liu Bo
2012-10-24 9:55 ` Liu Bo
2012-10-24 10:45 ` [PATCH] Btrfs: drop locks before calling read_tree_block from get_old_root Jan Schmidt
2012-10-24 14:18 ` Liu Bo
2012-10-23 13:55 ` [PATCH 4/6] Btrfs: determine level of old roots Jan Schmidt
2012-10-23 15:31 ` Liu Bo
2012-10-23 13:55 ` [PATCH 5/6] Btrfs: fix extent buffer reference for tree mod log roots Jan Schmidt
2012-10-23 15:32 ` Liu Bo
2012-10-23 13:55 ` [PATCH 6/6] Btrfs: comment for loop in tree_mod_log_insert_move Jan Schmidt
2012-10-23 15:32 ` Liu Bo
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=5086B677.7050905@oracle.com \
--to=bo.li.liu@oracle.com \
--cc=chris.mason@fusionio.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=list.btrfs@jan-o-sch.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).