From: Amy Parker <enbyamy@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
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 12:22:50 -0800 [thread overview]
Message-ID: <CAE1WUT61OwLSSRCvEe3FLjAASre42iOe=UfPX4uDbDrQ11PAYg@mail.gmail.com> (raw)
In-Reply-To: <20210126191716.GN308988@casper.infradead.org>
On Tue, Jan 26, 2021 at 11:18 AM Matthew Wilcox <willy@infradead.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)
next prev parent reply other threads:[~2021-01-27 3:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-26 16:23 Getting a new fs in the kernel 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
2021-01-26 20:22 ` Amy Parker [this message]
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='CAE1WUT61OwLSSRCvEe3FLjAASre42iOe=UfPX4uDbDrQ11PAYg@mail.gmail.com' \
--to=enbyamy@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@infradead.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;
as well as URLs for NNTP newsgroup(s).