All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: David Sterba <dsterba@suse.cz>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 00/10] btrfs: backref cache cleanups
Date: Mon, 9 Dec 2024 09:01:14 -0500	[thread overview]
Message-ID: <20241209140114.GB2840216@perftesting> (raw)
In-Reply-To: <20241206193854.GL31418@twin.jikos.cz>

On Fri, Dec 06, 2024 at 08:38:54PM +0100, David Sterba wrote:
> On Thu, Oct 03, 2024 at 11:43:02AM -0400, Josef Bacik wrote:
> > Hello,
> > 
> > This is the followup to the relocation fix that I sent out earlier.  This series
> > cleans up a lot of the complicated things that exist in backref cache because we
> > were keeping track of changes to the file system during relocation.  Now that we
> > do not do this we can simplify a lot of the code and make it easier to
> > understand.  I've tested this with the horror show of a relocation test I was
> > using to trigger the original problem.  I'm running fstests now via the CI, but
> > this seems solid.  Hopefully this makes the relocation code a bit easier to
> > understand.  Thanks,
> > 
> > Josef
> > 
> > Josef Bacik (10):
> >   btrfs: convert BUG_ON in btrfs_reloc_cow_block to proper error
> >     handling
> >   btrfs: remove the changed list for backref cache
> >   btrfs: add a comment for new_bytenr in bacref_cache_node
> >   btrfs: cleanup select_reloc_root
> >   btrfs: remove clone_backref_node
> >   btrfs: don't build backref tree for cowonly blocks
> >   btrfs: do not handle non-shareable roots in backref cache
> >   btrfs: simplify btrfs_backref_release_cache
> >   btrfs: remove the ->lowest and ->leaves members from backref cache
> >   btrfs: remove detached list from btrfs_backref_cache
> 
> The patches have been in misc-next as I've been expecting an update. We
> want the cleanups so I've applied the series to for-next. I've removed
> th ASSERT(0) callls, we need proper macros/functions in case you really
> want to see something fail during development. As the errors are EUCLEAN
> they'll bubble up eventually with some noisy message so I hope we're not
> losing much.

Sorry Dave, I let this one fall through the cracks, thanks for picking it up for
me.

As for replacing ASSERT(0) I agree this is a blunt tool.  Maybe we could have a
macro that we put around EUCLEAN, at least in these cases where it also
indicates we might have broken something?  Something like

#ifdef CONFIG_BTRFS_DEBUG
#define BTRRFS_EUCLEAN ({ WARN_ON(1); -EUCLEAN; })
#else
#define BTRFS_EUCLEAN -EUCLEAN
#endif

And then we can just use BTRFS_EUCLEAN to replace the ASSERT(0) calls.  Thanks,

Josef

  reply	other threads:[~2024-12-09 14:01 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-03 15:43 [PATCH 00/10] btrfs: backref cache cleanups Josef Bacik
2024-10-03 15:43 ` [PATCH 01/10] btrfs: convert BUG_ON in btrfs_reloc_cow_block to proper error handling Josef Bacik
2024-10-08 17:29   ` David Sterba
2024-10-03 15:43 ` [PATCH 02/10] btrfs: remove the changed list for backref cache Josef Bacik
2024-10-03 15:43 ` [PATCH 03/10] btrfs: add a comment for new_bytenr in bacref_cache_node Josef Bacik
2024-10-03 21:34   ` Boris Burkov
2024-10-03 15:43 ` [PATCH 04/10] btrfs: cleanup select_reloc_root Josef Bacik
2024-10-03 21:27   ` Boris Burkov
2024-10-03 15:43 ` [PATCH 05/10] btrfs: remove clone_backref_node Josef Bacik
2024-10-03 15:43 ` [PATCH 06/10] btrfs: don't build backref tree for cowonly blocks Josef Bacik
2024-10-03 21:36   ` Boris Burkov
2024-10-03 15:43 ` [PATCH 07/10] btrfs: do not handle non-shareable roots in backref cache Josef Bacik
2024-10-03 15:43 ` [PATCH 08/10] btrfs: simplify btrfs_backref_release_cache Josef Bacik
2024-10-03 15:43 ` [PATCH 09/10] btrfs: remove the ->lowest and ->leaves members from backref cache Josef Bacik
2024-10-03 15:43 ` [PATCH 10/10] btrfs: remove detached list from btrfs_backref_cache Josef Bacik
2024-10-03 21:39 ` [PATCH 00/10] btrfs: backref cache cleanups Boris Burkov
2024-12-06 19:38 ` David Sterba
2024-12-09 14:01   ` Josef Bacik [this message]
2024-12-10 23:24     ` 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=20241209140114.GB2840216@perftesting \
    --to=josef@toxicpanda.com \
    --cc=dsterba@suse.cz \
    --cc=kernel-team@fb.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 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.