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]

Message-ID: <20210126191716.GN308988@casper.infradead.org>
Date:   Tue, 26 Jan 2021 19:17:16 +0000
From:   Matthew Wilcox <willy@...radead.org>
To:     Amy Parker <enbyamy@...il.com>
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 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.

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.

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.

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.

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.