linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Pankaj Raghav <kernel@pankajraghav.com>
Cc: Jan Kara <jack@suse.cz>, Luis Chamberlain <mcgrof@kernel.org>,
	Pankaj Raghav <p.raghav@samsung.com>,
	linux-ext4@vger.kernel.org, Zhang Yi <yi.zhang@huaweicloud.com>,
	Baokun Li <libaokun1@huawei.com>
Subject: Re: LBS support for EXT4
Date: Mon, 23 Jun 2025 10:17:53 -0400	[thread overview]
Message-ID: <20250623141753.GA33354@mit.edu> (raw)
In-Reply-To: <279f3612-ca02-46e0-a4ae-05052f2b1e50@pankajraghav.com>

If you want to review and test the ext4/iomap changes, that would be
great.  Be aware, though, that there are some features of ext4
(example: data journalling, fscrypt, fsverity, etc.) that the current
iomap buffered I/O code may not support today.  The alternatives are
to keep the existing ext4 code paths for those file system features,
or to try to add that functionality into iomap.  There are of course
tradeoffs to both alternatives; one might result in more code that we
have to maintain; the other might require a lot more work.

It _might_ be less effort to add LBS support to native ext4 code.  I
think the main thing is to make sure that we always we use a large
folio and not fall back to a sub-blocksize set of pages.  So again,
it's all about tradeoffs and what you consider to be the highest
priority.

For myself, my primary concern is to keep the code maintainable and to
not result in any test regressions.  If your goal is to get more file
systems to use iomap for buffered I/O, that might be different than
those who are aiming to get performance or improved hardware support
ASAP as your higher priority.  I will say that in the ideal world, we
would eventually migrate to use the iomap code for buffered I/O for at
least the most common case.  But if we end up having an intermediate
way station where we have large folio support for LBS before we get to
that desired end state, I'm open to that, so long as the code stays
maintainable and bug-free(tm).   :-)

Cheers,

						- Ted

  reply	other threads:[~2025-06-23 14:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6ac7ce67-b54b-437e-9409-7da9402c9de1@pankajraghav.com>
2025-06-20 15:55 ` LBS support for EXT4 Jan Kara
2025-06-21  0:25   ` Baokun Li
2025-06-21  2:54   ` Zhang Yi
2025-06-23 13:22     ` Pankaj Raghav
2025-06-23 13:14   ` Pankaj Raghav
2025-06-23 14:17     ` Theodore Ts'o [this message]
2025-06-25 11:13       ` Pankaj Raghav (Samsung)
2025-06-25 11:51         ` Baokun Li
2025-06-25 12:25           ` Pankaj Raghav (Samsung)
2025-06-25 12:39           ` Theodore Ts'o
     [not found] <c0ea5334-6439-4ec9-a1eb-a9eb0863c3b7@pankajraghav.com>
2025-10-09  8:07 ` LBS support for ext4 Zhang Yi
2025-10-09  8:38   ` Pankaj Raghav

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=20250623141753.GA33354@mit.edu \
    --to=tytso@mit.edu \
    --cc=jack@suse.cz \
    --cc=kernel@pankajraghav.com \
    --cc=libaokun1@huawei.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=p.raghav@samsung.com \
    --cc=yi.zhang@huaweicloud.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;
as well as URLs for NNTP newsgroup(s).