Re: Getting a new fs in the kernel

[Amy Parker]

On Tue, Jan 26, 2021 at 9:15 AM Andreas Dilger <adilger@xxxxxxxxx> wrote:
>
> On Jan 26, 2021, at 09:25, Amy Parker <enbyamy@xxxxxxxxx> 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.
>
> 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 reboot,
> 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 that
> 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 be
> 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)