All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Burkov <boris@bur.io>
To: David Sterba <dsterba@suse.cz>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH] btrfs: hold block_group refcount during async discard
Date: Fri, 13 Jan 2023 12:43:11 -0800	[thread overview]
Message-ID: <Y8HCX0bDfPbvRg0G@zen> (raw)
In-Reply-To: <20230113132625.GV11562@twin.jikos.cz>

On Fri, Jan 13, 2023 at 02:26:25PM +0100, David Sterba wrote:
> On Thu, Jan 12, 2023 at 04:05:11PM -0800, Boris Burkov wrote:
> > Async discard does not acquire the block group reference count while it
> > holds a reference on the discard list. This is generally OK, as the
> > paths which destroy block groups tend to try to synchronize on
> > cancelling async discard work. However, relying on cancelling work
> > requires careful analysis to be sure it is safe from races with
> > unpinning scheduling more work.
> > 
> > While I am unable to find a race with unpinning in the current code for
> > either the unused bgs or relocation paths, I believe we have one in an
> > older version of auto relocation in a Meta internal build. This suggests
> > that this is in fact an error prone model, and could be fragile to
> > future changes to these bg deletion paths.
> 
> Which version is that? I'll add stable tag anyway but for a cross
> reference from a real deployment. Thanks.

I misunderstood the state of our branch. The code we were running has
Johannes's original patches for the reclaim worker and an internal only
patch that removes the pinned check. So I don't think there is any
commit in your tree which lacks the pinned check.

  reply	other threads:[~2023-01-13 20:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13  0:05 [PATCH] btrfs: hold block_group refcount during async discard Boris Burkov
2023-01-13 13:26 ` David Sterba
2023-01-13 20:43   ` Boris Burkov [this message]
2023-01-19  0:21 ` Qu Wenruo
2023-01-19  1:08   ` Qu Wenruo
2023-01-19 11:51   ` David Sterba
2023-01-19 19:20   ` 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=Y8HCX0bDfPbvRg0G@zen \
    --to=boris@bur.io \
    --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.