From: Luis Chamberlain <mcgrof@kernel.org>
To: lsf-pc@lists.linux-foundation.org,
Christoph Hellwig <hch@infradead.org>,
Matthew Wilcox <willy@infradead.org>,
David Howells <dhowells@redhat.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
"kbus >> Keith Busch" <kbusch@kernel.org>,
Pankaj Raghav <p.raghav@samsung.com>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: LSF/MM/BPF 2023 IOMAP conversion status update
Date: Sat, 28 Jan 2023 20:46:45 -0800 [thread overview]
Message-ID: <20230129044645.3cb2ayyxwxvxzhah@garbanzo> (raw)
One of the recurring themes that comes up at LSF is "iomap has little
to no documentation, it is hard to use". I've only recently taken a
little nose dive into it, and so I also can frankly admit to say I don't
grok it well either yet. However, the *general* motivation and value is clear:
avoiding the old ugly monster of struct buffer_head, and abstracting
the page cache for non network filesystems, and that is because for
network filesystems my understanding is that we have another side effort
for that. We could go a bit down memory lane on prior attempts to kill
the struct buffer_head evil demon from Linux, or why its evil, but I'm not
sure if recapping that is useful at this point in time, let me know, I could
do that if it helps if folks want to talk about this at LSF. For now I rather
instead focus on sharing efforts to review where we are today on the effort
towards conversion towards IOMAP for some of the major filesystems:
https://docs.google.com/presentation/d/e/2PACX-1vSN4TmhiTu1c6HNv6_gJZFqbFZpbF7GkABllSwJw5iLnSYKkkO-etQJ3AySYEbgJA/pub?start=true&loop=false&delayms=3000&slide=id.g189cfd05063_0_225
I'm hoping this *might* be useful to some, but I fear it may leave quite
a bit of folks with more questions than answers as it did for me. And
hence I figured that *this aspect of this topic* perhaps might be a good
topic for LSF. The end goal would hopefully then be finally enabling us
to document IOMAP API properly and helping with the whole conversion
effort.
My gatherings from this quick review of API evolution and use is that,
XFS is *certainly* a first class citizen user. No surprise there if a
lot of the effort came out from XFS. And even though btrfs now avoids
the evil struct buffer_head monster, its use of the IOMAP API seems
*dramatically* different than XFS, and it probably puzzles many. Is it
that btrfs managed to just get rid of struct buffer_head use but missed
fully abstracting working with the page cache? How does one check? What
semantics do we look for?
When looking to see if one can help on the conversion front with other
filesystems it begs the question what is the correct real end goal. What
should one strive for? And it also gets me wondering, if we wanted to abstract
the page cache from scratch again, would we have done this a bit differently
now? Are there lessons from the network filesystem side of things which
can be shared? If so it gets me wondering if this instead should be
about why that's a good idea and what should that look like.
Perhaps fs/buffers.c could be converted to folios only, and be done
with it. But would we be loosing out on something? What would that be?
Luis
next reply other threads:[~2023-01-29 4:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-29 4:46 Luis Chamberlain [this message]
2023-01-29 5:06 ` Matthew Wilcox
2023-01-29 5:39 ` Luis Chamberlain
2023-02-08 16:04 ` Jan Kara
2023-02-24 7:01 ` Zhang Yi
2023-02-26 20:16 ` Ritesh Harjani
2023-03-16 14:40 ` [RFCv1][WIP] ext2: Move direct-io to use iomap Ritesh Harjani (IBM)
2023-03-16 15:41 ` Darrick J. Wong
2023-03-20 16:11 ` Ritesh Harjani
2023-03-20 13:15 ` Christoph Hellwig
2023-03-20 17:51 ` Jan Kara
2023-03-22 6:34 ` Ritesh Harjani
2023-03-23 11:30 ` Jan Kara
2023-03-23 13:19 ` Ritesh Harjani
2023-03-30 0:02 ` Christoph Hellwig
2023-02-27 19:26 ` LSF/MM/BPF 2023 IOMAP conversion status update Darrick J. Wong
2023-02-27 21:02 ` Matthew Wilcox
2023-02-27 19:47 ` Darrick J. Wong
2023-02-27 20:24 ` Luis Chamberlain
2023-02-27 19:06 ` Darrick J. Wong
2023-02-27 19:58 ` Luis Chamberlain
2023-03-01 16:59 ` Ritesh Harjani
2023-03-01 17:08 ` Darrick J. Wong
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=20230129044645.3cb2ayyxwxvxzhah@garbanzo \
--to=mcgrof@kernel.org \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=kbusch@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=p.raghav@samsung.com \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox