From: Filipe Manana <fdmanana@gmail.com>
To: Zhao Lei <zhaolei@cn.fujitsu.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] btrfs: Fix lost-data-profile caused by auto removing bg
Date: Wed, 30 Sep 2015 17:19:03 +0100 [thread overview]
Message-ID: <CAL3q7H5B=ByJBr819u_WM7Z3apd4fMG958vz6shDGv6T3vCYgQ@mail.gmail.com> (raw)
In-Reply-To: <aaa2dcf7018bd29459e20f0571ff490fe1abee51.1443611403.git.zhaolei@cn.fujitsu.com>
On Wed, Sep 30, 2015 at 12:11 PM, Zhao Lei <zhaolei@cn.fujitsu.com> wrote:
> Reproduce:
> (In integration-4.3 branch)
>
> TEST_DEV=(/dev/vdg /dev/vdh)
> TEST_DIR=/mnt/tmp
>
> umount "$TEST_DEV" >/dev/null
> mkfs.btrfs -f -d raid1 "${TEST_DEV[@]}"
>
> mount -o nospace_cache "$TEST_DEV" "$TEST_DIR"
> umount "$TEST_DEV"
>
> mount -o nospace_cache "$TEST_DEV" "$TEST_DIR"
> btrfs filesystem usage $TEST_DIR
>
> We can see the data chunk changed from raid1 to single:
> # btrfs filesystem usage $TEST_DIR
> Data,single: Size:8.00MiB, Used:0.00B
> /dev/vdg 8.00MiB
> #
>
> Reason:
> When a empty filesystem mount with -o nospace_cache, the last
> data blockgroup will be auto-removed in umount.
>
> Then if we mount it again, there is no data chunk in the
> filesystem, so the only available data profile is 0x0, result
> is all new chunks are created as single type.
>
> Fix:
> Don't auto-delete last blockgroup for a raid type.
>
> Test:
> Test by above script, and confirmed the logic by debug output.
>
> Changelog v1->v2:
> 1: Put code of checking block_group->list into
> semaphore of space_info->groups_sem.
> Noticed-by: Filipe Manana <fdmanana@gmail.com>
>
> Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
I would have made the check in the "if" statement below that is
already done while holding a write lock on the semaphore (smaller code
diff), but this is equally correct.
thanks
> ---
> fs/btrfs/extent-tree.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 79a5bd9..ed9426c 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -10010,8 +10010,18 @@ void btrfs_delete_unused_bgs(struct btrfs_fs_info *fs_info)
> block_group = list_first_entry(&fs_info->unused_bgs,
> struct btrfs_block_group_cache,
> bg_list);
> - space_info = block_group->space_info;
> list_del_init(&block_group->bg_list);
> +
> + space_info = block_group->space_info;
> +
> + down_read(&space_info->groups_sem);
> + if (block_group->list.next == block_group->list.prev) {
> + up_read(&space_info->groups_sem);
> + btrfs_put_block_group(block_group);
> + continue;
> + }
> + up_read(&space_info->groups_sem);
> +
> if (ret || btrfs_mixed_space_info(space_info)) {
> btrfs_put_block_group(block_group);
> continue;
> --
> 1.8.5.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Filipe David Manana,
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
next prev parent reply other threads:[~2015-09-30 16:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 11:11 [PATCH v2 1/2] btrfs: Fix lost-data-profile caused by auto removing bg Zhao Lei
2015-09-30 11:11 ` [PATCH v2 2/2] btrfs: Fix lost-data-profile caused by balance bg Zhao Lei
2015-09-30 16:17 ` Filipe Manana
2015-09-30 16:19 ` Filipe Manana [this message]
2015-10-01 14:44 ` [PATCH v2 1/2] btrfs: Fix lost-data-profile caused by auto removing bg Jeff Mahoney
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='CAL3q7H5B=ByJBr819u_WM7Z3apd4fMG958vz6shDGv6T3vCYgQ@mail.gmail.com' \
--to=fdmanana@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=zhaolei@cn.fujitsu.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 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).