Re: Getting a new fs in the kernel

[Amy Parker]

On Tue, Jan 26, 2021 at 9:36 PM Theodore Ts'o <tytso@xxxxxxx> wrote:
>
> On Tue, Jan 26, 2021 at 07:06:55PM +0000, Chaitanya Kulkarni wrote:
> > From what I've seen you can post the long patch-series as an RFC and get the
> >
> > discussion started.
> >
> > The priority should be ease of review and not the total patch-count.
>
> File systems are also complicated enough that it's useful to make the
> patches available via a git repo, and it's highly recommended that you
> are rebasing it against the latest kernel on a regular basis.

Was already setting up some local git infrastructure for this.

>
> I also strongly recommend that once you get something that mostly
> works, that you start doing regression testing of the file system.

"'Regression testing? What's that? If it compiles, it is good; if it
boots up, it is perfect."

In all seriousness, though, yeah, already been planning for stuff like that.

> Most of the major file systems in Linux use xfstests for their
> testing.

Decently familiar with xfstests, used it for some previous change
testing I had to do.

> One of the things that I've done is to package up xfstests
> as a test appliance, suitable for running under KVM or using Google
> Compute Engine, as a VM, to make it super easy for people to run
> regression tests.  (One of my original goals for packaging it up was
> to make it easy for graduate students who were creating research file
> systems to try running regression tests so they could find potential
> problems --- and understand how hard it is to make a robust,
> production-ready file system, by giving them a realtively well
> documented, turn-key system for running file system regression tests.)
>
> For more information, see:
>
>     https://thunk.org/gce-xfstests
>     https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md
>     https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-xfstests.md
>     https://github.com/tytso/xfstests-bld/blob/master/Documentation/gce-xfstests.md

Thank you so much for that!

>
> The final thing I'll point out is that file system development is a
> team sport.  Industry estimates are that it takes between 50 and 200
> person-years to create a production-ready, general purpose enterprise
> file system.  For example, ZFS took seven years to develop, starting
> with a core team of 4, and growing to over 14 developers by the time
> it was announced.  And that didn't include all of the QA, release
> engineering, testers, performance engineers, to get it integrated into
> the Solaris product.  Even after it was announced, it was a good four
> years before customers trusted it for production workloads.

Wasn't expecting to do that completely solo, I get that it takes a
significant amount of people time to build something as important as a
production filesystem. Once I get some basic stuff lined out for it,
if I decide to continue, already working on getting people to help
assist with its development.

>
> If you look at the major file systems in Linux: ext4, xfs, btrfs,
> f2fs, etc., you'll find that none of them are solo endeavors, and all
> of them have multiple companies who are employing the developers who
> work on them.  Figuring out how to convince companies that there are
> good business reasons for them to support the developers of your file
> system is important, since in order to keep things going for the long
> haul, it really needs to be more than a single person's hobby.

Yeah, got that.

>
> Good luck!
>
>                                         - Ted

Thank you!

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