[RFC] Maintainership of the EFS filesystem

[RFC] Maintainership of the EFS filesystem

[Maxwell Doose]

Hi Christian, Al,

I recently sent a patch for the EFS filesystem [1]. While writing that
patch, which fixed code that was now incompatible with the latest GCC
(+ an undefined variable), I discovered that the EFS filesystem was
orphaned and without a maintainer. I inquired with Andrew Morton, the
person who merged my patch, about potentially taking over
maintainership for EFS. He noted that he was fine with it [2], and he
directed me to Christian regarding this possibility. As the subject
suggests, I'd like to take over maintainership of EFS, if it's fine
with you all.

-- 
best regards.
max

[1] https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/fs-efs-remove-unneeded-debug-prints.patch
[2] https://lore.kernel.org/mm-commits/20260605193524.f277071da69189161e84e327@linux-foundation.org/

Re: [RFC] Maintainership of the EFS filesystem

[Matthew Wilcox]

On Fri, Jun 05, 2026 at 09:52:19PM -0500, Maxwell Doose wrote:
> Hi Christian, Al,
> 
> I recently sent a patch for the EFS filesystem [1]. While writing that
> patch, which fixed code that was now incompatible with the latest GCC
> (+ an undefined variable), I discovered that the EFS filesystem was
> orphaned and without a maintainer. I inquired with Andrew Morton, the
> person who merged my patch, about potentially taking over
> maintainership for EFS. He noted that he was fine with it [2], and he
> directed me to Christian regarding this possibility. As the subject
> suggests, I'd like to take over maintainership of EFS, if it's fine
> with you all.

As I said, I don't see the point.  Do you have any EFS filesystems?
Are you volunteering to do any major development on it?  Why shouldn't
we just delete it?

Re: [RFC] Maintainership of the EFS filesystem

[Maxwell Doose]

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.

> Why shouldn't we just delete it?

Because in my eyes it's an awful practice to just delete something
overnight (probably not your plan but still), I think we need to have
some maintenance for some time before this gets removed.

Re: [RFC] Maintainership of the EFS filesystem

[Al Viro]

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?

FWIW, I've no preferences re efs fate; a simple block-based r/o filesystem
is not a serious burden, provided that there's somebody to take care of
conversions on API changes (mount options parsing work, stuff like that).
However, that really assumes that there's some way to test such changes.

So the first question is whether such images can be found.  If not, there's
no point whatsoever - neither in kernel nor in userland.  If they are available,
it might make a useful learning experience...

Re: [RFC] Maintainership of the EFS filesystem

[Darrick J. Wong]

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.
> 
> > Why shouldn't we just delete it?
> 
> Because in my eyes it's an awful practice to just delete something
> overnight (probably not your plan but still), I think we need to have
> some maintenance for some time before this gets removed.

How do you plan to do QA with the EFS driver?  Is there a mkfs or fsck
program for it?  I don't see one in Debian, though I didn't search that
hard.

--D

Re: [RFC] Maintainership of the EFS filesystem

[Maxwell Doose]

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?
>
> FWIW, I've no preferences re efs fate; a simple block-based r/o filesystem
> is not a serious burden, provided that there's somebody to take care of
> conversions on API changes (mount options parsing work, stuff like that).
> However, that really assumes that there's some way to test such changes.
>
> So the first question is whether such images can be found.  If not, there's
> no point whatsoever - neither in kernel nor in userland.  If they are available,
> it might make a useful learning experience...

After a quick google search (and take this with a grain of salt), the
utilities to do so are not compatible whatsoever with modern versions
of Linux, however it is possible to emulate the environment in which
one could create an image. I would also guess that images for EFS
filesystems, disks, etc have been archived on the internet.

Re: [RFC] Maintainership of the EFS filesystem

[Maxwell Doose]

On Fri, Jun 5, 2026 at 11:21 PM Darrick J. Wong <djwong@kernel.org> 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.
> >
> > > Why shouldn't we just delete it?
> >
> > Because in my eyes it's an awful practice to just delete something
> > overnight (probably not your plan but still), I think we need to have
> > some maintenance for some time before this gets removed.
>
> How do you plan to do QA with the EFS driver?  Is there a mkfs or fsck
> program for it?  I don't see one in Debian, though I didn't search that
> hard.

I also sent this email to Al, but my guess is that there are
images/disks archived on the internet that we can use for testing, so
we can just compile the kernel module and mount an EFS image. I also
did a quick google search and found that the utilities can be emulated
to create new images, but I imagine that that would be much more
difficult then getting images off of the internet.

Re: [RFC] Maintainership of the EFS filesystem

[Maxwell Doose]

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.

-- 
best regards,
max

Re: [RFC] Maintainership of the EFS filesystem

[Jori Koolstra]

On Fri, Jun 05, 2026 at 09:52:19PM -0500, Maxwell Doose wrote:
> Hi Christian, Al,
> 
> I recently sent a patch for the EFS filesystem [1]. While writing that
> patch, which fixed code that was now incompatible with the latest GCC
> (+ an undefined variable), I discovered that the EFS filesystem was
> orphaned and without a maintainer. I inquired with Andrew Morton, the
> person who merged my patch, about potentially taking over
> maintainership for EFS. He noted that he was fine with it [2], and he
> directed me to Christian regarding this possibility. As the subject
> suggests, I'd like to take over maintainership of EFS, if it's fine
> with you all.
> 

Hi!

Thanks for looking into EFS. I am not sure whether it makes sense to
have a maintainer for just EFS. The only reason this (and some other)
old filesystems are still in tree is because we don't really know much
about their users. Linux strongly emphasizes stability of user space, so
we don't just rip them out. Ideally, they should be replaced with a FUSE
driver and removed, but no one has stepped up to do this (for good
reasons).

What would perhaps make sense is to have someone maintain API
compatibility for all old filesystems, to unburden the vfs maintainers.
This maintainer would just be focused on ensuring that modern API is
ported, so that the old stuff can be removed. But that does require some
expertise while it might not add much.

Thanks,
Jori.
> -- 
> best regards.
> max
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/fs-efs-remove-unneeded-debug-prints.patch
> [2] https://lore.kernel.org/mm-commits/20260605193524.f277071da69189161e84e327@linux-foundation.org/

Re: [RFC] Maintainership of the EFS filesystem

[Mateusz Guzik]

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 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.

Note there is no write support.

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).

So... I don't believe there is any practical value in keeping the fs,
even for hobbyists.

Perhaps you could submit a removal instead.

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.

Re: [RFC] Maintainership of the EFS filesystem

[Maxwell Doose]

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)