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

[Jeff Layton <jlayton@kernel.org>]

On Thu, 2025-10-30 at 13:22 +0100, Jori Koolstra wrote:
> Hi Jan,
> 
> > 
> > The patch looks ok to me but since minix filesystem driver is in the kernel
> > mostly to allow mounting ancient unix filesystems I don't quite understand
> > the motivation for adding the new mount options. Why not just fixup
> > minix_rmdir() to better handle corrupted filesystems?
> > 
> > 								Honza
> 
> I am doing the Linux kernel mentorship program, and was looking to contribute
> to fs. Since I saw a lot bugs on syzbot related to minix (and jfs too) not
> handling corruptions well (yielding warnings in drop_nlink e.g.) I figured
> it was a low stakes project, not completely trivial, yet within my scope, to
> attempt to implement what ext4 does for these kind of problems (and jfs
> implements the same opts too).
> 
> I would have asked about the exact status of minix, but was told not to
> bother maintainers without a patch. I would be open with trying to improve
> minix further, but of course if there are better options to get it out of
> the kernel altogether that may be better. Sad for me, since that means still
> zero patches, but that is not your problem :)
> 

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.

> Anyway, I hope this clarifies why I submitted this patch.

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.
-- 
Jeff Layton <jlayton@kernel.org>