Re: [PATCH] Add error handling to minix filesystem similar to ext4

[Jeff Layton <jlayton@kernel.org>]

On Thu, 2025-10-30 at 14:31 +0100, Jori Koolstra wrote:
> > Not necessarily.
> > 
> > I'm not sure if your internship covers this, but you could start a
> > project to build a minixfs FUSE fs (if one doesn't already exist). If
> > you get it working and stable, you can then submit patches to deprecate
> > and remove it from the kernel.
> 
> 
> I would have to ask Shuah but am open to it. But a quick search turns up
> this: https://github.com/redcap97/fuse-mfs . I would have to see if it
> actually works and it does not seem to support v1, v2 of minix fs either.
> There might also be a licensing issue.
> 

I don't see a licensing issue. It's BSD licensed. Also, this is a
userland code, so we wouldn't need to worry about that too much.
 
> > For some background: this is a continuation of a discussion that we had
> > at LSF/MM summit this year. A lot of these smaller, less-used
> > filesystems represent a significant maintenance burden. Whenever we
> > have to make changes at the VFS layer, they represent another fs that
> > we have to touch.
> 
> > Many of these are not performance-critical and are hard to test. They
> > would be _much_ easier to maintain in userland if we can make that
> > work.
> 
> One question I would have about this is that if we move minix, for
> instance, out of the kernel code, how can we be sure that it is
> maintained. What if some Github repo suddenly disappears? Like I said,
> I would be fine with helping maintain minix, otherwise what should be
> the course of action from here? What demands do we place on a userland
> replacement for minix before I submit a patch to deprecate and remove
> the code?
> 

These are great questions that I don't think we have an answer for just
yet.

In practice, FUSE interfaces are quite stable, and the minixfs format
also doesn't change a lot. Much like minixfs in the kernel, I wouldn't
expect that it would require a lot of maintenance itself over the long
haul (but everything requires _some_). It might need some to keep up
with broader OS changes, but that's not usually too burdensome.

You're quite right though that userland replacements will need to meet
some criteria before we can rip out the in-kernel versions. This might
be a good discussion topic for next year's LSF/MM!
-- 
Jeff Layton <jlayton@kernel.org>