From: Christoph Hellwig <hch@lst.de>
To: Chris Mason <clm@fb.com>
Cc: linux-btrfs@vger.kernel.org, dsterba@suse.com,
josef@toxicpanda.com, hch@lst.de
Subject: Re: [PATCH v2] Btrfs: only subtract from len_to_oe_boundary when it is tracking an extent
Date: Tue, 1 Aug 2023 18:42:42 +0200 [thread overview]
Message-ID: <20230801164242.GA13927@lst.de> (raw)
In-Reply-To: <20230801162828.1396380-1-clm@fb.com>
On Tue, Aug 01, 2023 at 09:28:28AM -0700, Chris Mason wrote:
> + * When len_to_oe_boundary is U32_MAX, the cap above would
> + * result in a 4095 byte IO for the last page riiiiight before
> + * we hit the bio limit of UINT_MAX. bio_add_page() has all
> + * the checks required to make sure we don't overflow the bio,
> + * and we should just ignore len_to_oe_boundary completely
> + * unless we're using it to track an ordered extent.
> + *
> + * It's pretty hard to make a bio sized U32_MAX, but it can
> + * happen when the page cache is able to feed us contiguous
> + * pages for large extents.
> + */
> + if (bio_ctrl->len_to_oe_boundary != U32_MAX)
So I don't know the btrfs extent allocator, but what is the maximum
size of an extent? Could there be an U32_MAX sized extent that could
be hitting this? In other words, what about adding an explicit flag
to bio_ctrl when to check the boundary, and just don't bother with
len_to_oe_boundary at all if it isn't set.
next prev parent reply other threads:[~2023-08-01 16:42 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 [this message]
2023-08-01 17:29 ` Chris Mason
2023-08-02 9:35 ` Christoph Hellwig
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=20230801164242.GA13927@lst.de \
--to=hch@lst.de \
--cc=clm@fb.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.