From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>,
Theodore Ts'o <tytso@mit.edu>,
Matthew Wilcox <willy@infradead.org>,
linux-ext4@vger.kernel.org
Subject: Re: [LSF/MM/BPF TOPIC]: Challenges and Ideas in Transitioning EXT* and other FS to iomap
Date: Sat, 24 Feb 2024 15:49:23 +0530 [thread overview]
Message-ID: <87y1ba17x0.fsf@doe.com> (raw)
In-Reply-To: <871q922v9u.fsf@doe.com>
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com> writes:
++ linux-ext4
> In continuation from last year's efforts on conversion of ext* filesystems to iomap,
> I would like to propose an LSFMM session on the said topic. Last year's session
> was mainly centered around documentation discussion around iomap (so that it can help others
> converting their filesystems to iomap), and I think we now have a kernelnewbies page [1]
> which can provide good details on how one can start transitioning their filesystem to iomap
> interface.
>
> Note, ext2/ext4 filesystems direct-io path now utilizes iomap where ext2
> DIO conversion happened last year during LSFMM [2] [3]. I have also submitted patches
> for ext2 buffered-io path for regular files to move to iomap and thereby enabling
> large folio support to it. Along similar lines there are also patches around EXT4
> buffered-io conversion to iomap.
>
> Some of the challenges
> =======================
> 1. For EXT2 directory handling which uses page cache and buffer heads, moving that path to
> iomap has challenges with writeback path since iomap also uses folio->private to keep some
> of its internal state (iomap_folio_state).
> 2. One other thing which was pointed out by Matthew is the BH_Boundary handling currently missing
> in iomap. This can lead to non-optimized data I/O patterns causing performance penalty.
> 3. Filesystems need a mechanism to validate cached logical->physical block translations
> in iomap writeback code (can this be lifted to common code?)
> 4. Another missing piece from iomap is the metadata handling for filesystems. There is no
> interface which iomap provides that the FS can utilize to move away from buffer heads
> for its metadata operations. It can be argued that it is not the responsibility of iomap, however
> filesystems do need a mechanism for their metadata handling operations.
>
> Proposal
> =========
> In this talk I would like to discuss about the efforts, challenges & the lessons learnt in doing the conversion of
> ext2's DIO and buffered-io paths to iomap, which might help others in conversion of their filesystem.
> I would also like to have a discussion on the current open challenges we have in converting ext2 (buffered-io path)
> and discuss on what ideas people have, which we can consider for transitioning ext* and other filesystems to iomap.
>
> PS: As we speak, I am in the process of rebasing ext2 bufferred-io path to latest upstream kernel.
> It's mostly done and I am also looking into some of the open problems listed by community.
>
>
> References
> ============
> [1]: https://kernelnewbies.org/KernelProjects/iomap
> [2]: https://lore.kernel.org/linux-ext4/cover.1682069716.git.ritesh.list@gmail.com/
> [3]: https://lwn.net/Articles/935934/
> [4]: https://lore.kernel.org/linux-ext4/cover.1700505907.git.ritesh.list@gmail.com/
next prev parent reply other threads:[~2024-02-24 10:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-24 7:09 [LSF/MM/BPF TOPIC]: Challenges and Ideas in Transitioning EXT* and other FS to iomap Ritesh Harjani (IBM)
2024-02-24 10:19 ` Ritesh Harjani [this message]
2024-03-06 11:09 ` Ritesh Harjani
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=87y1ba17x0.fsf@doe.com \
--to=ritesh.list@gmail.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=tytso@mit.edu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.