From: Matthew Wilcox <willy@infradead.org>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Goldwyn Rodrigues <rgoldwyn@suse.com>
Subject: Re: [PATCH 01/12] iomap: check if folio size is equal to FS block size
Date: Sat, 5 Oct 2024 03:17:47 +0100 [thread overview]
Message-ID: <ZwChy4jNCP6gJNJ0@casper.infradead.org> (raw)
In-Reply-To: <b25b678264d02e411cb2c956207e2acd95188e4c.1728071257.git.rgoldwyn@suse.com>
On Fri, Oct 04, 2024 at 04:04:28PM -0400, Goldwyn Rodrigues wrote:
> Filesystems such as BTRFS use folio->private so that they receive a
> callback while releasing folios. Add check if folio size is same as
> filesystem block size while evaluating iomap_folio_state from
> folio->private.
>
> I am hoping this will be removed when all of btrfs code has moved to
> iomap and BTRFS uses iomap's subpage.
This seems like a terrible explanation for why you need this patch.
As I understand it, what you're really doing is saying that iomap only
uses folio->private for block size < folio size. So if you add this
hack, iomap won't look at folio->private for block size == folio size
and that means that btrfs can continue to use it.
I don't think this is a good way to start the conversion. I appreciate
that it's a long, complex procedure, and you can't do the whole
conversion in a single patchset.
Also, please stop calling this "subpage". That's btrfs terminology,
it's confusing as hell, and it should be deleted from your brain.
But I don't understand why you need it at all. btrfs doesn't attach
private data to folios unless block size < page size. Which is precisely
the case that you're not using. So it seems like you could just drop
this patch and everything would still work.
next prev parent reply other threads:[~2024-10-05 2:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-04 20:04 [PATCH 00/12] btrfs reads through iomap Goldwyn Rodrigues
2024-10-04 20:04 ` [PATCH 01/12] iomap: check if folio size is equal to FS block size Goldwyn Rodrigues
2024-10-05 2:17 ` Matthew Wilcox [this message]
2024-10-07 16:57 ` Darrick J. Wong
2024-10-10 17:59 ` Goldwyn Rodrigues
2024-10-08 9:40 ` Christoph Hellwig
2024-10-04 20:04 ` [PATCH 02/12] iomap: Introduce iomap_read_folio_ops Goldwyn Rodrigues
2024-10-05 2:20 ` Matthew Wilcox
2024-10-07 17:01 ` Darrick J. Wong
2024-10-08 9:43 ` Christoph Hellwig
2024-10-04 20:04 ` [PATCH 03/12] iomap: add bioset in iomap_read_folio_ops for filesystems to use own bioset Goldwyn Rodrigues
2024-10-08 9:45 ` Christoph Hellwig
2024-10-10 17:51 ` Goldwyn Rodrigues
2024-10-04 20:04 ` [PATCH 04/12] iomap: include iomap_read_end_io() in header Goldwyn Rodrigues
2024-10-07 17:02 ` Darrick J. Wong
2024-10-10 18:12 ` Goldwyn Rodrigues
2024-10-04 20:04 ` [PATCH 05/12] iomap: Introduce IOMAP_ENCODED Goldwyn Rodrigues
2024-10-08 9:48 ` Christoph Hellwig
2024-10-10 9:42 ` Christoph Hellwig
2024-10-10 17:50 ` Goldwyn Rodrigues
2024-10-15 3:43 ` Ritesh Harjani
2024-10-04 20:04 ` [PATCH 06/12] iomap: Introduce read_inline() function hook Goldwyn Rodrigues
2024-10-05 2:30 ` Matthew Wilcox
2024-10-07 17:47 ` Darrick J. Wong
2024-10-10 18:10 ` Goldwyn Rodrigues
2024-10-11 0:43 ` Dave Chinner
2024-10-11 3:28 ` Gao Xiang
2024-10-11 4:52 ` Dave Chinner
2024-10-11 5:19 ` Gao Xiang
2024-10-04 20:04 ` [PATCH 07/12] btrfs: btrfs_em_to_iomap() to convert em to iomap Goldwyn Rodrigues
2024-10-04 20:04 ` [PATCH 08/12] btrfs: iomap_begin() for buffered reads Goldwyn Rodrigues
2024-10-04 20:04 ` [PATCH 09/12] btrfs: define btrfs_iomap_read_folio_ops Goldwyn Rodrigues
2024-10-04 20:04 ` [PATCH 10/12] btrfs: define btrfs_iomap_folio_ops Goldwyn Rodrigues
2024-10-04 20:04 ` [PATCH 11/12] btrfs: add read_inline for folio operations for read() calls Goldwyn Rodrigues
2024-10-04 20:04 ` [PATCH 12/12] btrfs: switch to iomap for buffered reads Goldwyn Rodrigues
2024-10-08 9:39 ` [PATCH 00/12] btrfs reads through iomap Christoph Hellwig
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=ZwChy4jNCP6gJNJ0@casper.infradead.org \
--to=willy@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rgoldwyn@suse.com \
--cc=rgoldwyn@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).