linux-kernel - Re: Getting a new fs in the kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 26 Jan 2021 12:22:50 -0800
From:   Amy Parker <enbyamy@...il.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Getting a new fs in the kernel

On Tue, Jan 26, 2021 at 11:18 AM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Tue, Jan 26, 2021 at 08:23:03AM -0800, Amy Parker wrote:
> > Kernel development newcomer here. I've begun creating a concept for a
> > new filesystem, and ideally once it's completed, rich, and stable I'd
> > try to get it into the kernel.
> >
> > What would be the process for this? I'd assume a patch sequence, but
> > they'd all be dependent on each other, and sending in tons of
> > dependent patches doesn't sound like a great idea. I've seen requests
> > for pulls, but since I'm new here I don't really know what to do.
>
> Hi Amy,
>
> Writing a new filesystem is fun!  Everyone should do it.
>
> Releasing a filesystem is gut-churning.  You're committing to a filesystem
> format that has to be supported for ~ever.

I'm bored and need something to dedicate myself to as a long-term commitment.

>
> Supporting a new filesystem is a weighty responsibility.  People are
> depending on you to store their data reliably.  And they demand boring
> and annoying features like xattrs, acls, support for time after 2038.



>
> We have quite a lot of actively developed filesystems for users to choose
> from already -- ext4, btrfs, xfs are the main three.  So you're going
> to face a challenge persuading people to switch.
>

Yeah, understandable.

> Finally, each filesystem represents a (small) maintainance burden to
> people who need to make changes that cross all filesystems.  So it'd
> be nice to have a good justification for why we should include that
> cost.

Alright, I'll keep that in mind.

>
> Depending exactly what your concept is, it might make more sense to
> make it part of an existing filesystem.  Or develop it separately
> and have an existing filesystem integrate it.

That's what other people have suggested as well, so I'll start
considering trying to add any features I come up with into other
filesystems as well.

>
> Anyway, I've been at this for twenty years, so maybe I'm just grouchy
> about new filesystems.  By all means work on it and see if it makes
> sense, but there's a fairly low probability that it gets merged.

Alright. Thanks for the advice!

Best regards,
Amy Parker
(she/her/hers)