linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boris Burkov <boris@bur.io>
To: Leo Martins <loemra.dev@gmail.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH v2 0/2] btrfs-progs: mkfs free-space-info bug
Date: Wed, 2 Oct 2024 11:45:14 -0700	[thread overview]
Message-ID: <20241002184514.GC3917419@zen.localdomain> (raw)
In-Reply-To: <cover.1727732460.git.loemra.dev@gmail.com>

On Mon, Sep 30, 2024 at 03:23:10PM -0700, Leo Martins wrote:
> Currently mkfs creates a few block-groups to bootstrap the filesystem.
> Along with these block-groups some free-space-infos are created. When
> the block-group cleanup happens the block-groups are deleted and the
> free-space-infos are not. This patch set introduces a fix that deletes
> the free-space-infos when the block-groups are deleted.
> 
> When implementing a test for my changes I found that there was already
> some code in free-space-tree.c that attempts to verify that all
> free-space-infos correspond to a block-group. This code only checks if
> there exists a block-group that has an objectid >= free-space-info's
> objectid. I added an additional check to make sure that the block-group
> actually matches the free-space-info's objectid and offset.
> 
> Making this change to fsck will cause all filesystems that were created
> using mkfs.btrfs to warn that there is some free-space-info that doesn't
> correspond to a block-group. This seems like a bad idea, I considered
> adding to the message to signify that this is not a big issue and maybe
> point them to this patchset to get the fix. Open to ideas on how to
> handle this.

A few thoughts:
- You should also add a diagnostic to the in-kernel tree checker (but not
  one that flips us read-only)
- You can add support in check --repair for removing the free space info
- I don't think it hurts to use some softer language in the warning, but
  fundamentally people are going to be hitting it and dealing with it
  eventually, so better to do include it than not. Otherwise, it's just
  a timebomb until we write some kernel logic that DOES choke on this
  problem.

  I don't think there is a precedent for a very soft warning in fsck
  output, but if there is, let's just follow that. I certainly wouldn't
  hate links to a wiki, for example :)

Boris

> 
> Leo Martins (2):
>   btrfs-progs: delete free space when deleting block group
>   btrfs-progs: check free space maps to block group
> 
>  common/clear-cache.c            |  3 ++-
>  kernel-shared/extent-tree.c     | 10 ++++++++++
>  kernel-shared/free-space-tree.c |  3 +++
>  3 files changed, 15 insertions(+), 1 deletion(-)
> 
> -- 
> 2.43.5
> 

      parent reply	other threads:[~2024-10-02 18:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-30 22:23 [PATCH v2 0/2] btrfs-progs: mkfs free-space-info bug Leo Martins
2024-09-30 22:23 ` [PATCH v2 1/2] btrfs-progs: remove block group free space Leo Martins
2024-09-30 22:23 ` [PATCH v2 2/2] btrfs-progs: check free space maps to block group Leo Martins
2024-10-01 20:21 ` [PATCH v2 0/2] btrfs-progs: mkfs free-space-info bug Josef Bacik
2024-10-02 18:45 ` Boris Burkov [this message]

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=20241002184514.GC3917419@zen.localdomain \
    --to=boris@bur.io \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=loemra.dev@gmail.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).