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 RFC] Btrfs: only subtract from len_to_oe_boundary when it is tracking an extent
Date: Mon, 31 Jul 2023 09:00:25 +0200 [thread overview]
Message-ID: <20230731070025.GA31096@lst.de> (raw)
In-Reply-To: <20230730190226.4001117-1-clm@fb.com>
On Sun, Jul 30, 2023 at 12:02:26PM -0700, Chris Mason wrote:
> [ This is an RFC because Christoph switched us to almost always set
> len_to_oe_boundary in a patch in for-next I think we still need this
> commit for strange corners, but it's already pretty hard to hit reliably
> so I wanted to toss it out for discussion. We should consider either
> Christoph's "btrfs: limit write bios to a single ordered extent" or this
> commit for 6.4 stable as well ]
I'm torn. On the one hand "btrfs: limit write bios to a single ordered
extent" is a pretty significant behavior change, on the other hand
stable-only patches with totally different behavior are always a bit
strange.
Note that with my entire pending queue, len_to_oe_boundary goes away
entirely, but with the current speed of patch application it might take
another 6 to 8 month to get there.
> This is hard to trigger because bio_add_page() isn't going to make a bio
> of U32_MAX size unless you give it a perfect set of pages and fully
> contiguous extents on disk. We can hit it pretty reliably while making
> large swapfiles during provisioning because the machine is freshly
> booted, mostly idle, and the disk is freshly formatted.
It might be useful to create and xfstests for that, even if it only
hits on a freshly booted machine, although we'll need some reordering
in the xfstests sequence to make sure it gets run early..
next prev parent reply other threads:[~2023-07-31 7:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-30 19:02 [PATCH RFC] Btrfs: only subtract from len_to_oe_boundary when it is tracking an extent Chris Mason
2023-07-30 20:27 ` Sweet Tea Dorminy
2023-07-31 19:22 ` Chris Mason
2023-08-01 2:59 ` Sweet Tea Dorminy
2023-07-31 2:27 ` Qu Wenruo
2023-07-31 7:02 ` Christoph Hellwig
2023-07-31 18:10 ` Chris Mason
2023-08-01 0:58 ` Qu Wenruo
2023-07-31 7:00 ` Christoph Hellwig [this message]
2023-07-31 18:52 ` Chris Mason
2023-07-31 19:35 ` Christoph Hellwig
2023-07-31 21:05 ` Chris Mason
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=20230731070025.GA31096@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.