All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: David Sterba <dsterba@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>, Chris Mason <clm@fb.com>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	"open list:BTRFS FILE SYSTEM" <linux-btrfs@vger.kernel.org>,
	naohiro.aota@wdc.com
Subject: Re: [PATCH 3/3] btrfs: don't hold an extra reference for redirtied buffers
Date: Mon, 15 May 2023 11:22:54 +0200	[thread overview]
Message-ID: <20230515092254.GA21580@lst.de> (raw)
In-Reply-To: <20230509225737.GK32559@twin.jikos.cz>

On Wed, May 10, 2023 at 12:57:37AM +0200, David Sterba wrote:
> On Mon, May 08, 2023 at 07:58:39AM -0700, Christoph Hellwig wrote:
> > When btrfs_redirty_list_add redirties a buffer, it also acquires
> > an extra reference that is released on transaction commit.  But
> > this is not required as buffers that are dirty or under writeback
> > are never freed (look for calls to extent_buffer_under_io())).
> > 
> > Remove the extra reference and the infrastructure used to drop it
> > again.
> 
> I vaguely remember that the redirty list was need for zoned to avoid
> some write pattern that disrupts the ordering, added in d3575156f662
> ("btrfs: zoned: redirty released extent buffers").

So the redirting itself is needed for that - without it buffers where
the dirty bit wasn't ever set would never get written, leading to a
write outside of the zone pointer.  But the extra reference can't
influece the write pattern, as we don't make writeback descriptions
based of it.

> I'd appreciate more eyes on this patch, with the indirections and
> writeback involved it's not clear to me that we don't need the list at
> all.

My suspicision is that Aoto-san wanted the extra safety of the extra
reference because he didn't want to trust or hadn't noticed the
extent_buffer_under_io() magic.  Auto-san, can you confirm or deny? :)

  reply	other threads:[~2023-05-15  9:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-08 14:58 buffer redirtying fixes and cleanup Christoph Hellwig
2023-05-08 14:58 ` [PATCH 1/3] btrfs: zero the buffer before marking it dirty in btrfs_redirty_list_add Christoph Hellwig
2023-05-08 14:58 ` [PATCH 2/3] btrfs: fix dirty_metadata_bytes for redirtied buffers Christoph Hellwig
2023-05-08 14:58 ` [PATCH 3/3] btrfs: don't hold an extra reference " Christoph Hellwig
2023-05-09 22:57   ` David Sterba
2023-05-15  9:22     ` Christoph Hellwig [this message]
2023-05-30 15:56       ` David Sterba
2023-05-31  4:16         ` Christoph Hellwig
2023-05-31 15:04           ` Naohiro Aota
2023-06-05 15:58             ` 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=20230515092254.GA21580@lst.de \
    --to=hch@lst.de \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=dsterba@suse.cz \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=naohiro.aota@wdc.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 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.