Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAE1WUT7xJyx_gbxJu3r9DJGbqSkWZa-moieiDWC0bue2CxwAwg@mail.gmail.com>
 <D66E412C-ED63-4FF7-A0F9-C78EF846AAF4@dilger.ca>
In-Reply-To: <D66E412C-ED63-4FF7-A0F9-C78EF846AAF4@dilger.ca>
From:   Amy Parker <enbyamy@gmail.com>
Date:   Tue, 26 Jan 2021 09:28:11 -0800
Message-ID: <CAE1WUT5phUhqhQgsC82c8pZXBPZ3Aj+TarpGwhSFP=XK6jHQog@mail.gmail.com>
Subject: Re: Getting a new fs in the kernel
To:     Andreas Dilger <adilger@dilger.ca>
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Jan 26, 2021 at 9:15 AM Andreas Dilger <adilger@dilger.ca> wrote:
>
> On Jan 26, 2021, at 09:25, Amy Parker <enbyamy@gmail.com> wrote:
> >
> > =EF=BB=BFKernel development newcomer here. I've begun creating a concep=
t for a
> > new filesystem, and ideally once it's completed, rich, and stable I'd
> > try to get it into the kernel.
>
> Hello Amy, and welcome.
>
> I guess the first question to ask is what would be unique and valuable
> about the new filesystem compared to existing filesystems in the kernel?

Currently planning those bits out.

>
> Given that maintaining a new filesystem adds ongoing maintenance
> efforts, there has to be some added value before it would be accepted.
> Also, given that filesystems are storing critical data for users, and
> problems in the code can lead to data loss that can't be fixed by a reboo=
t,
> like many other software bugs, it takes a very long time for filesystems
> to become stable enough for general use (the general rule of thumb is 10
> years before a new filesystem is stable enough for general use).

Yeah, I understood that. Wasn't expecting this to go quickly or
anything, just wanted to know for the future.

>
> Often, if you have ideas for new functionality, it makes more sense to
> add this into the framework of an existing filesystem (e.g. data verity,
> data encryption, metadata checksum, DAX, etc. were all added to ext4).

Been considering doing this too.

>
> Not only does this simplify efforts in terms of ongoing maintenance, but
> it also means many more users will benefit from your development effort
> in a much shorter timeframe. Otherwise, users would have to stop
> using their existing filesystem before
> they started using yours, and that is
> a very slow process, because your filesystem would have to be much
> better at *something* before they would make that switch.

True, alright.

>
> > 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.
>
> Probably the first step, before submitting any patches, would be to
> provide a description of your work, and how it improves on the current
> filesystems in the kernel. It may be that there are existing projects tha=
t
> duplicate this effort, and combining resources will result in a 100% done
> filesystem rather than two 80% done
> projects...

Alright, if I continue on with this I'll do that.

>
> Note that I don't want to discourage you from participating in the Linux
> filesystem development community, but there are definitely considerations
> going both ways wrt. accepting a new filesystem into the kernel. It may b=
e
> that your ideas, time, and efforts are better spent in contributing to an
> exiting project.  It may also be that you have something groundbreaking
> work, and I look forward to reading about what that is.

Alright, thank you so much!

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