From: Jeremy Bingham <jbingham@gmail.com>
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, brauner@kernel.org,
jkoolstra@xs4all.nl, jack@suse.cz, djwong@kernel.org,
viro@zeniv.linux.org.uk, hch@infradead.org,
Jeremy Bingham <jbingham@gmail.com>
Subject: [PATCH v4 0/3] minix: convert to iomap
Date: Wed, 26 Aug 2026 14:41:54 -0700 [thread overview]
Message-ID: <cover.1787770110.git.jbingham@gmail.com> (raw)
This is version 4 of the minix iomap conversion patch series. Versions 1
and 2 had issues uncovered by syzbot. Version 3 fixed those and
addressed some critiques given by Darrick J. Wong, while in turn having
issues pointed out by Christoph Hellwig and Darrick J. Wong including
having direct I/O in the patch series and proper testing. This version
addresses those criticisms.
The rationale for converting minix to use iomap instead of buffer heads
is pretty simple: it both provides a very basic example of a filesystem
using iomap, and it makes it easier to keep the minix filesystem in the
kernel in the future. It is a rarely used bit of computer history, but
it's one that's significant to Linux's early history. Plus, filesystems
are a hard subject to approach. Having a very simple filesystem in the
mainline kernel tree as an example for aspiring kernel filesystem
hackers would be good to help them learn.
Per Christoph Hellwig's remarks in the previous version of this patch
series, the direct I/O support has been removed. The iomap_symlink_write
function has also been reworked to be more useful for symlinks. The
original implementation of that function was proposed by Darrick J. Wong
as an alternative to the custom buffer head implementation symlink
function I had previously that sidestepped iomap for symlinks entirely.
One thing reviewers may find in here that seems very odd is the way that
iomap.c is included in itree_v1.c and itree_v2.c. This is in common with
how itree_common.c is included in those files and minix has been like
this at least as far back as the git history goes, and probably back
into the 90s. Not including iomap.c in itree_v1.c and itree_v2.c is
technically possible, but ended up being a massive headache to make
iomap.c stand by itself while itree_common.c is included in itree_v1.c
and itree_v2.c. Re-architecting minix to not require these separate
itree files with different versions of basic functions depending on the
version of the filesystem in question is possible, but definitely out of
scope for this patch series. If there is interest I could pick up a
patch series I made a little while back, dust it off, and give it
another go, but it's a pretty big change for a rarely touched
filesystem. I will defer to the collective wiser heads on that.
It is not possible to run xfstests against the minix filesystems with a
vanilla xfstests-dev repository because mkfs.minix and fsck.minix do not
support the proper options. There were some changes required in
'common/rc' to sidestep that issue, which fortunately did not require
any changes to mkfs.minix or fsck.minix. Once the tests were able to
run, there are also many tests that fail miserably because of inherent
limitations in all versions of the minix filesystems. Since these
failures aren't "bugs" as such, I then updated xfstests to skip the
tests that would never pass so I could focus on actual potential
failures and regressions.
Across all versions of the minix filesystems, there are 81 tests
skipped. Sixty-eight of them are unique to the minix V1 filesystem,
while an additional 13 are common to all versions. The exact breakdown
of skipped tests will be given at the end of this cover letter. I have
created a git repository forked from the main xfstests-dev repository to
share these changes for running minix tests. The minix branch can be
found at https://github.com/ctdk/xfstests-dev/tree/minix.
Leaving the skipped tests out, the iomap patch does not introduce any
new failures compared to the baseline in the master linux branch. The
iomap patches do fix a test that fails on v1 and v3 (but not v2):
generic/472, which tests swapfiles. After the patch, v1 and v3 will
properly report that swapfiles are not supported and the test is
skipped. Other than that, everything is the same and there are no
regressions.
This patch series has also been verified to build between each patch
being applied. Additionally, the minix module continues to function
between each patch.
======
The breakdown of the skipped xfstests:
13 tests skipped for all minix versions:
003, 075, 112, 127, 169, 249, 338, 347, 363, 563, 616, 676, 759
These failures relate to atime/ctime semantics, fallocate not being
supported, copy_file_range not being supported, sendfile not being
supported, FS_IOC_GETXATTR not being supported, not supporting dm-thin
cleanup properly, not supporting cgroup2 writeback accounting, not
handling I/O errors while unmounting, and not supporting filenames long
enough to be able to run the test.
These tests test features that no version of minix supports.
68 skipped only for minix v1. Of those, 52 are skipped because the 64MB
minix v1 filesystem fills up while the test is running:
013, 035, 074, 080, 087, 089, 100, 126, 131, 215, 245, 246, 248, 257,
309, 310, 313, 346, 394, 409, 410, 411, 430, 431, 432, 433, 434, 438,
443, 464, 471, 564, 565, 585, 589, 632, 633, 637, 638, 639, 650, 696,
712, 713, 715, 718, 719, 723, 724, 725, 732, 736, 741, 742, 754, 763
2 are skipped because minix v1 does not support fallocate at all.
749, 758
4 fail because fallocate is unsupported and the 64MB filesystem limit.
340, 344, 345, 354
Another 6 tests fail for their own reasons:
124: An aligned vector rw pattern test. Fails with output mismatch.
132: Another aligned vector rw test. Fails because the v1 fs is too
small for large writes.
192: An atime persistence test. Fails because v1 atime/ctime is wonky.
428: DAX mmap test. Minix does not support DAX.
706: A seek sanity check. Fails for v1.
707: Testing directory modification race condition during rename. The v1
directory link limit is too small to run the test.
======
Jeremy Bingham (3):
iomap: add iomap_symlink_write
minix: add iomap functions and definitions
minix: finish wiring in iomap functions
fs/iomap/buffered-io.c | 34 +++++++++++
fs/minix/file.c | 30 +++++++++-
fs/minix/inode.c | 85 ++++++++++++++++++++++++----
fs/minix/iomap.c | 122 ++++++++++++++++++++++++++++++++++++++++
fs/minix/itree_common.c | 10 +++-
fs/minix/itree_v1.c | 25 +++++++-
fs/minix/itree_v2.c | 17 +++++-
fs/minix/minix.h | 23 +++++++-
fs/minix/namei.c | 7 ++-
include/linux/iomap.h | 3 +
10 files changed, 336 insertions(+), 20 deletions(-)
create mode 100644 fs/minix/iomap.c
--
2.47.3
next reply other threads:[~2026-08-26 21:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 21:41 Jeremy Bingham [this message]
2026-08-26 21:41 ` [PATCH v4 1/3] iomap: add iomap_symlink_write Jeremy Bingham
2026-08-26 21:41 ` [PATCH v4 2/3] minix: add iomap functions and definitions Jeremy Bingham
2026-08-26 21:41 ` [PATCH v4 3/3] minix: finish wiring in iomap functions Jeremy Bingham
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=cover.1787770110.git.jbingham@gmail.com \
--to=jbingham@gmail.com \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jkoolstra@xs4all.nl \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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