From: Christoph Hellwig <hch@lst.de>
To: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
Cc: "Christoph Hellwig" <hch@lst.de>, "Chris Mason" <clm@fb.com>,
"Josef Bacik" <josef@toxicpanda.com>,
"David Sterba" <dsterba@suse.com>,
"Naohiro Aota" <Naohiro.Aota@wdc.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"Matias Bjørling" <Matias.Bjorling@wdc.com>,
"Damien Le Moal" <dlemoal@kernel.org>
Subject: Re: don't split ordered_extents for zoned writes at I/O submission time
Date: Tue, 30 May 2023 16:20:10 +0200 [thread overview]
Message-ID: <20230530142009.GA8807@lst.de> (raw)
In-Reply-To: <45d88c8a-4eab-6fc2-8970-6224878940a1@wdc.com>
On Tue, May 30, 2023 at 01:21:14PM +0000, Johannes Thumshirn wrote:
> Btw, as this came up multiple times today, should we also add a patch on top
> of this series merging consecutive ordered extents if the on disk extents are
> consecutive as well?
>
> This would reduce fragmentation that unfortunately is a byproduct of the
> Zone Append writing scheme.
With this series we don't split ordered extents for zoned writes unless
they are non-consecutive. So I'm not sure what we should merge, as
there isn't any splitting going on unless either a block group didn't
have space, or zone append actually reordered.
next prev parent reply other threads:[~2023-05-30 14:22 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-24 15:03 don't split ordered_extents for zoned writes at I/O submission time Christoph Hellwig
2023-05-24 15:03 ` [PATCH 01/14] btrfs: optimize out btrfs_is_zoned for !CONFIG_BLK_DEV_ZONED Christoph Hellwig
2023-05-25 8:33 ` Johannes Thumshirn
2023-05-24 15:03 ` [PATCH 02/14] btrfs: don't call btrfs_record_physical_zoned for failed append Christoph Hellwig
2023-05-25 8:33 ` Johannes Thumshirn
2023-05-24 15:03 ` [PATCH 03/14] btrfs: mark the len field in struct btrfs_ordered_sum as unsigned Christoph Hellwig
2023-05-25 8:33 ` Johannes Thumshirn
2023-05-30 16:45 ` David Sterba
2023-05-24 15:03 ` [PATCH 04/14] btrfs: rename the bytenr field in struct btrfs_ordered_sum to logical Christoph Hellwig
2023-05-25 8:33 ` Johannes Thumshirn
2023-05-24 15:03 ` [PATCH 05/14] btrfs: optimize the logical to physical mapping for zoned writes Christoph Hellwig
2023-05-25 10:56 ` Johannes Thumshirn
2023-08-18 14:03 ` Naohiro Aota
2023-05-24 15:03 ` [PATCH 06/14] btrfs: move split_extent_map to extent_map.c Christoph Hellwig
2023-05-25 10:58 ` Johannes Thumshirn
2023-05-24 15:03 ` [PATCH 07/14] btrfs: reorder btrfs_extract_ordered_extent Christoph Hellwig
2023-05-24 15:03 ` [PATCH 08/14] btrfs: return the new ordered_extent from btrfs_split_ordered_extent Christoph Hellwig
2023-05-24 15:03 ` [PATCH 09/14] btrfs: return void from btrfs_finish_ordered_io Christoph Hellwig
2023-05-25 11:02 ` Johannes Thumshirn
2023-05-30 15:44 ` David Sterba
2023-05-31 4:00 ` Christoph Hellwig
2023-05-24 15:03 ` [PATCH 10/14] btrfs: split btrfs_alloc_ordered_extent Christoph Hellwig
2023-05-25 12:09 ` Johannes Thumshirn
2023-05-24 15:03 ` [PATCH 11/14] btrfs: atomically insert the new extent in btrfs_split_ordered_extent Christoph Hellwig
2023-05-25 12:30 ` Johannes Thumshirn
2023-05-25 12:34 ` Christoph Hellwig
2023-05-25 16:23 ` Johannes Thumshirn
2023-05-24 15:03 ` [PATCH 12/14] btrfs: handle completed ordered extents " Christoph Hellwig
2023-05-25 13:06 ` Johannes Thumshirn
2023-05-24 15:03 ` [PATCH 13/14] btrfs: defer splitting of ordered extents until I/O completion Christoph Hellwig
2023-05-25 16:25 ` Johannes Thumshirn
2023-05-30 18:40 ` David Sterba
2023-05-24 15:03 ` [PATCH 14/14] btrfs: pass the new logical address to split_extent_map Christoph Hellwig
2023-05-25 16:28 ` Johannes Thumshirn
2023-05-30 13:21 ` don't split ordered_extents for zoned writes at I/O submission time Johannes Thumshirn
2023-05-30 14:20 ` Christoph Hellwig [this message]
2023-05-30 18:48 ` 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=20230530142009.GA8807@lst.de \
--to=hch@lst.de \
--cc=Johannes.Thumshirn@wdc.com \
--cc=Matias.Bjorling@wdc.com \
--cc=Naohiro.Aota@wdc.com \
--cc=clm@fb.com \
--cc=dlemoal@kernel.org \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.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