From: Josef Bacik <josef@toxicpanda.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Boris Burkov <boris@bur.io>,
linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH] btrfs: adjust subpage bit start based on sectorsize
Date: Wed, 16 Apr 2025 10:16:46 -0400 [thread overview]
Message-ID: <20250416141646.GA2778901@perftesting> (raw)
In-Reply-To: <7ad4df86-866e-40ce-89a1-48f3c49aeeea@gmx.com>
On Wed, Apr 16, 2025 at 09:19:37AM +0930, Qu Wenruo wrote:
>
>
> 在 2025/4/16 01:46, Boris Burkov 写道:
> > On Tue, Apr 15, 2025 at 08:07:08AM +0930, Qu Wenruo wrote:
> [...]
> > > >
> > > > The problem is, we can not ensure all extent buffers are nodesize aligned.
> > > >
> >
> > In theory because the allocator can do whatever it wants, or in practice
> > because of mixed block groups? It seems to me that in practice without
> > mixed block groups they ought to always be aligned.
>
> Because we may have some old converted btrfs, whose allocater may not ensure
> nodesize aligned bytenr.
>
> For subpage we can still support non-aligned tree blocks as long as they do
> not cross boundary.
>
> I know this is over-complicated and prefer to reject them all, but such a
> change will need quite some time to reach end users.
>
> >
> > > > If we have an eb whose bytenr is only block aligned but not node size
> > > > aligned, this will lead to the same problem.
> > > >
> >
> > But then the existing code for the non error path is broken, right?
> > How was this intended to work? Is there any correct way to loop over the
> > ebs in a folio when nodesize < pagesize? Your proposed gang lookup?
> >
> > I guess to put my question a different way, was it intentional to mix
> > the increment size in the two codepaths in this function?
>
> Yes, that's intended, consider the following case:
>
> 32K page size, 16K node size.
>
> 0 4K 8K 16K 20K 24K 28K 32K
> | |///////////////////| |
>
> In above case, for offset 0 and 4K, we didn't find any dirty block, and skip
> to next block.
>
> For 8K, we found an eb, submit it, and jump to 24K, and that's the expected
> behavior.
>
> But on the other hand, if at offset 0 we increase the offset by 16K, we will
> never be able to grab the eb at 8K.
Right, but this can't actually happen can it? I mean it could happen the first
eb, but as soon as we allocate eb->start 24k we would fail check_eb_alignment()
because it straddles a folio and then the fs would flipe RO. So I don't think
this is a problem in general. Thanks,
Josef
next prev parent reply other threads:[~2025-04-16 14:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-14 19:08 [PATCH] btrfs: adjust subpage bit start based on sectorsize Josef Bacik
2025-04-14 19:54 ` Boris Burkov
2025-04-14 22:08 ` Qu Wenruo
2025-04-14 22:37 ` Qu Wenruo
2025-04-15 16:16 ` Boris Burkov
2025-04-15 23:49 ` Qu Wenruo
2025-04-16 14:16 ` Josef Bacik [this message]
2025-04-16 22:07 ` Qu Wenruo
2025-04-15 17:25 ` Josef Bacik
2025-04-16 0:08 ` Qu Wenruo
2025-04-15 17:23 ` Josef Bacik
2025-04-15 23:53 ` Qu Wenruo
-- strict thread matches above, loose matches on Subject: below --
2025-04-21 13:37 Josef Bacik
2025-04-21 20:17 ` Qu Wenruo
2025-04-24 10:40 ` Daniel Vacek
2025-04-24 20:57 ` Qu Wenruo
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=20250416141646.GA2778901@perftesting \
--to=josef@toxicpanda.com \
--cc=boris@bur.io \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox