Re: [RFC] Maintainership of the EFS filesystem

[Maxwell Doose <m32285159@gmail.com>]

On Mon, 8 Jun 2026 00:50:58 +0200
Mateusz Guzik <mjguzik@gmail.com> wrote:

> On Sat, Jun 06, 2026 at 12:17:53AM -0500, Maxwell Doose wrote:
> > On Fri, Jun 5, 2026 at 11:28 PM Maxwell Doose <m32285159@gmail.com> wrote:  
> > >
> > > On Fri, Jun 5, 2026 at 11:21 PM Al Viro <viro@zeniv.linux.org.uk> wrote:  
> > > >
> > > > On Fri, Jun 05, 2026 at 11:02:44PM -0500, Maxwell Doose wrote:  
> > > > > On Fri, Jun 5, 2026 at 10:44 PM Matthew Wilcox <willy@infradead.org> wrote:  
> > > > > >
> > > > > > As I said, I don't see the point.  Do you have any EFS filesystems?  
> > > > >
> > > > > I don't personally have any EFS filesystems but that doesn't mean that
> > > > > others don't.
> > > > >  
> > > > > > Are you volunteering to do any major development on it?  
> > > > >
> > > > > Like I said, we've already found some problems, and like I said I'd
> > > > > like to fix those before it becomes a FUSE as you suggested. So I
> > > > > guess I'll volunteer to do some major development for it as well.  
> > > >
> > > > Out of curiosity - had there been anything beside the "some code that
> > > > had been ifdefed out since forever doesn't even build these days"
> > > > I've seen mentioned a while ago?
> > > >  
> > 
> > Forgot to answer this; I've been looking through the files and already
> > found more ifdefs but also a lot of style issues, most notably
> > trailing whitespace (eek!). I'm still auditing the files but it's 1am
> > over here so I'm going to continue in the morning.
> >   
> 
> A glance at your patch history suggests you are not tied to EFS in any
> capacity. By your admission you don't even use it.
> 
> It seems like you are just looking for an area to contribute to and
> figured EFS would make a good choice.
> 

I've already made a contribution to EFS [1], and I'm an active
contributor and driver maintainer in IIO [2] [3], to answer your point.

> I would argue EFS is an excellent candidate for git rm instead. Nobody
> knows if it even works. Even if it happens to work and it gets removed,
> the absolute worst case for anyone interested in extracting data from
> EFS is having to boot up a vm with an older kernel to do it. I think
> that's something the (likely non-existent) users can live with.

I think the general consensus is conversion to a FUSE as well. Then I
suppose while that gets written we give EFS one last chance at life in
fs/.

> Note there is no write support.

A quick google search suggests that EFS initially did support writing,
however it may be too complex to add in this kernel module since all
data is stored in what they call an "extent", basically a sequence of
sectors. In later versions of IRIX EFS was made read-only.

> I did a quick search and found the following userspace tooling:
> https://github.com/sgi-demos/sgi-efs2tar
> https://github.com/jkbenaim/efsextract
> 
> I have no idea if it works, presumably it does (and better than the
> kernel module).

Native support for EFS would be nice (for its users) but obviously your
point stands.

> So... I don't believe there is any practical value in keeping the fs,
> even for hobbyists.
> 
> Perhaps you could submit a removal instead.

Then if we eventually remove it, I personally would give EFS about 3
months before we do that, but vfs maintainers may think otherwise.

> If you are looking for something to do, there is plenty of non-obsolete
> code suffering all kinds of breakage. All it takes is picking an area
> and digging into it.

Would be willing to do that, I'd say it may be interesting to take a
look at more orphaned subsystems, drivers, etc.

-- 
best regards,
max

[1]https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-nonmm-unstable&id=0f79e1121b0d36808e600a86ab597f86d7b52a51
("fs: efs: remove unneeded debug prints")

[2]https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?h=togreg&id=4452b868d669fbf6d5333cd03ab2bd8fbadb91a3
("MAINTAINERS: Add myself as SCD30 maintainer")

[3]https://lore.kernel.org/linux-iio/20260607182215.3e6e849e@jic23-huawei/T/#u
(Jonathan Cameron's IIO pull request)