mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Amy Parker <enbyamy@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Getting a new fs in the kernel
Date: Tue, 26 Jan 2021 19:17:16 +0000	[thread overview]
Message-ID: <20210126191716.GN308988@casper.infradead.org> (raw)
In-Reply-To: <CAE1WUT7xJyx_gbxJu3r9DJGbqSkWZa-moieiDWC0bue2CxwAwg@mail.gmail.com>

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.

  parent reply	other threads:[~2021-01-27  6:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-26 16:23 Amy Parker
2021-01-26 17:15 ` Andreas Dilger
2021-01-26 17:28   ` Amy Parker
2021-01-26 19:06 ` Chaitanya Kulkarni
2021-01-26 20:17   ` Amy Parker
2021-01-27  5:36   ` Theodore Ts'o
2021-01-28  3:21     ` Amy Parker
2021-01-26 19:06 ` Randy Dunlap
2021-01-26 19:17 ` Matthew Wilcox [this message]
2021-01-26 20:22   ` Amy Parker
2021-01-28 21:26     ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210126191716.GN308988@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=enbyamy@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®