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

[Jan Kara]

On Thu 30-10-25 09:43:26, Jeff Layton wrote:
> On Thu, 2025-10-30 at 14:31 +0100, Jori Koolstra wrote:
> > 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!

Usually the requirement is feature parity - meaning if the kernel can read
/ write filesystem with some set of features, then the other drivers should
support that as well. Also passing the same set of fstests is a good
indication the replacement is sound. Darrick did quite some work with
making fstests work better for FUSE filesystems recently if I remember
correctly.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR