public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/3] btrfs-progs: mkfs: make sure we can clean up all temporary chunks
Date: Mon, 11 Oct 2021 20:06:47 +0800	[thread overview]
Message-ID: <20211011120650.179017-1-wqu@suse.com> (raw)

There is a bug report that with certain mkfs options, mkfs.btrfs may
fail to cleanup some temporary chunks, leading to "btrfs filesystem df"
warning about multiple profiles:

  WARNING: Multiple block group profiles detected, see 'man btrfs(5)'.
  WARNING:   Metadata: single, raid1 

The easiest way to reproduce is "mkfs.btrfs -f -R free-space-tree -m dup
-d dup".

It turns out that, the old _recow_root() can not handle tree levels > 0,
while with newer free space tree creation timing, the free space tree
can reach level 1 or higher.

To fix the problem, Patch 2 will do the proper full tree re-CoW, with
extra transaction commitment to make sure all free space tree get
re-CoWed.

The 3rd patch will do the extra verification during mkfs-tests.

The first patch is just to fix a confusing parameter which also caused
u64 -> int width reduction and can be problematic in the future.

Changelog:
v2:
- Remove a duplicated recow_roots() call in create_raid_groups()
  This call makes no difference as we will later commit transaction
  and manually call recow_roots() again.
  Remove such duplicated call to save some time.

- Replace the btrfs_next_sibling_tree_block() with btrfs_next_leaf()
  Since we're always handling leaves, there is no need for
  btrfs_next_sibling_tree_block()

- Work around a kernel bug which may cause false alerts
  For single device RAID0, btrfs kernel is not respecting it, and will
  allocate new chunks using SINGLE instead.
  This can be very noisy and cause false alerts, and not always
  reproducible, depending on how fast kernel creates new chunks.

  Work around it by mounting the RO before calling "btrfs fi df".

  The kernel bug needs to be investigated and fixed.


Qu Wenruo (3):
  btrfs-progs: rename @data parameter to @profile in extent allocation
    path
  btrfs-progs: mkfs: recow all tree blocks properly
  btrfs-progs: mfks-tests: make sure mkfs.btrfs cleans up temporary
    chunks

 kernel-shared/extent-tree.c                 | 26 +++---
 mkfs/main.c                                 | 90 ++++++++++++++++++---
 tests/mkfs-tests/001-basic-profiles/test.sh | 16 +++-
 3 files changed, 104 insertions(+), 28 deletions(-)

-- 
2.33.0


             reply	other threads:[~2021-10-11 12:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11 12:06 Qu Wenruo [this message]
2021-10-11 12:06 ` [PATCH v2 1/3] btrfs-progs: rename @data parameter to @profile in extent allocation path Qu Wenruo
2021-10-11 12:06 ` [PATCH v2 2/3] btrfs-progs: mkfs: recow all tree blocks properly Qu Wenruo
2021-10-11 14:34   ` David Sterba
2021-10-11 12:06 ` [PATCH v2 3/3] btrfs-progs: mfks-tests: make sure mkfs.btrfs cleans up temporary chunks Qu Wenruo
2021-10-11 14:38   ` David Sterba
2021-10-11 22:54     ` Qu Wenruo
2021-10-11 12:10 ` [PATCH v2 0/3] btrfs-progs: mkfs: make sure we can clean up all " Nikolay Borisov
2021-10-11 12:14   ` Qu Wenruo
2021-10-12  7:07     ` Qu Wenruo
2021-10-11 14:05 ` David Sterba
2021-10-11 14:39   ` David Sterba
2021-10-11 22:56     ` Qu Wenruo
2021-10-11 14:40 ` David Sterba

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=20211011120650.179017-1-wqu@suse.com \
    --to=wqu@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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