From: Christoph Hellwig <hch@lst.de>
To: Chris Mason <clm@meta.com>
Cc: Christoph Hellwig <hch@lst.de>, Chris Mason <clm@fb.com>,
linux-btrfs@vger.kernel.org, dsterba@suse.com,
josef@toxicpanda.com
Subject: Re: [PATCH v2] Btrfs: only subtract from len_to_oe_boundary when it is tracking an extent
Date: Wed, 2 Aug 2023 11:35:55 +0200 [thread overview]
Message-ID: <20230802093555.GA28141@lst.de> (raw)
In-Reply-To: <1a01a6ad-5374-a9f6-ee69-df78cae87428@meta.com>
On Tue, Aug 01, 2023 at 01:29:51PM -0400, Chris Mason wrote:
> The actual max extent size is limited to one chunk, which right now is
> max 10G and then we round down for various reasons.
Ok.
> For writes, I didn't actually audit the way we're setting
> len_to_oe_boundary vs U32_MAX. BTRFS_MAX_EXTENT_SIZE should save us
> from any single wild extents.
At leasr in older kernels U32_MAX is the default as we're only
looking up the ordered extent for zoned writes. This is changing
right now, though.
> Yeah, I'm just using (len_to_oe_boundary == U32_MAX) as the explicit
> flag, but your idea above is basically where I started. I actually
> started at len_to_oe_boundary = ROUND_DOWN(U32_MAX, PAGE_SIZE), but then
> I realized I'd have to actually think about sub-page blocksizes and went
> to the flag idea.
>
> Especially since the code is going away, I'd prefer a minimal change and
> a big comment, but I don't actually have strong opinions.
Ok:
Reviewed-by: Christoph Hellwig <hch@lst.de>
next prev parent reply other threads:[~2023-08-02 9:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-01 16:28 [PATCH v2] Btrfs: only subtract from len_to_oe_boundary when it is tracking an extent Chris Mason
2023-08-01 16:42 ` Christoph Hellwig
2023-08-01 17:29 ` Chris Mason
2023-08-02 9:35 ` Christoph Hellwig [this message]
2023-08-01 22:34 ` Qu Wenruo
2023-08-17 11:38 ` 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=20230802093555.GA28141@lst.de \
--to=hch@lst.de \
--cc=clm@fb.com \
--cc=clm@meta.com \
--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 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.