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)
