I wanna apply the project about file systems, especially the one improving btrfs. I like the features of btrfs like easy to backup. I am going to start my CS PhD from this summer. And my topic is about the storage and file systems. I am in my gap year now, so I want to participate in this project, it has a very close relation with my PhD topic. I built a simple kernel before and implemented a simple ext2-like fs in it.
I will first try to complete the writing function. If there remains time after finishing it, I may continue porting other FSs like xfs and bcachefs.
I have read the FAQs and the guidelines carefully. Is there anything I omit or need to do in order to increase the chance of being selected?
We already have, not only a compatibility layer for FUSE, but also for running filesystems developed for BeOS and for Haiku kernels (they use different APIs) in userspace.
Indeed if you plan to work in the area of filesystems, this can be very useful for testing your work (a lot less rebooting needed when you can simply unload and reload the filesystem code; you can also use a userspace debugger instead of the kernel one which is a lot less comfortable, etc).
I think there is enough work to do with one filesystem for GSoC, so if you want to submit a proposal for that, I recommend sticking to only one.
I think a good GSoC proposal for this should include:
An overview of the current state of the existing filesystem driver
What is missing, with references to existing documentation on the filesystem data structures and algorithms
And a plan for adding these features (maybe starting with simple writes and going up to more and more complex things such as snapshotting, etc).
I don’t think that Btrfs would be very useful because of various design issues. It cause data loss even on Linux and have various tricky troubles like inability to properly track empty space, sometimes making impossible to even remove files when disk become full. I think that it is better to spend effort for XFS or improving EXT4/FAT/NTFS.
Regardless of thoughts on BTRFS, it is however the second most common filesystem in the Linux world after ext4. XFS is largely relegated to RHEL, while ZFS would prolly be third most common. So, BTRFS makes quite a lot of sense to work on for Haiku.
Hmm, what about exFAT? The specs for that have been published, however patent-wise IDK if it’s only limited to Linux use.
Microsoft released the exFAT patent to the Open Invention Network back in 2019:
This allowed exFAT to be in the Linux kernel. Would Haiku be able to have exFAT support in-kernel it its current status or would Haiku Inc. need to become an OIN member first?
Did a search over the full OIN member list and there are some non-Linux OS organisations present:
dahilaOS (based on Linux and Fuchsia)
ReactOS Foundation
Redox OS
RIOT OS
So at least in theory, Haiku Inc. could join the OIN.
Edit:
After consulting with somebody more knowledgeable on this matter, even joining the OIN won’t mean that Haiku could use the exFAT patent until it expires. It has to fall under the OIN’s Linux System Definition, at least for the exFAT patent specifically. Disregard the suggestion.
Let’s see if we can provide a better implementation than Linux does. Some of these problems may be related only to their implementation, and not to the filesystem structures.
After reviewing it again, the workload exceed what I estimated before. So I have to adjust the timeline and the aim. I’ll focus on the file, directory, and hard link operations first, they are the highest priority. The sub-volume are the same priority as well cuz it work together with directories in Haiku. The rest features will be implemented if possible.