public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
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

  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