Hi,
I’m Anuj Billore, a CS student from India with strong C++
experience, interested in implementing btrfs write support
for GSoC 2026.
To get familiar with the project I have:
- Built Haiku from source successfully
- Run Haiku nightly image (hrev59451) in VirtualBox
- Joined #haiku and #haiku-3rdparty on OFTC IRC
- Subscribed to haiku-development, haiku, haiku-commits
and haiku-bugs mailing lists
- Joined the Haiku forums
I’ve studied the entire btrfs codebase in depth including:
- kernel_interface.cpp, Volume.cpp, Inode.cpp, BTree.cpp,
Journal.cpp, ExtentAllocator.cpp,etc
- Change 1531 (all 10 patchsets from 2019)
- GSoC 2017 and 2018 blog logs
- Existing btrfs patches on Gerrit
I’ve submitted several patches (topic: gsoc2026) including:
- Additional validation checks in IsValid()
- Hash collision fix in DirectoryIterator::Lookup()
- Style fixes in kernel_interface.cpp, btrfs_disk_system.cpp, Inode.h, AttributeIterator.h, BTree.cpp, ExtentAllocator.cpp, Volume.cpp
- Pointer arithmetic fix in WriteSuperBlock()
- Fix name access using entry->name in directory iterators
- Clarification in BTree::PreviousLeaf()
Would love feedback from mentors on the proposed scope
and whether 175 or 350 hours is more appropriate.
Thanks,
Anuj Billore
IRC: anujbillore (OFTC)
Gerrit: anujbillore-0-0
Trac: anujbillore
3 Likes
Hello,
What’s your proposed scope? Which part of the write support do you plan to implement? What’s missing in the current code?
It’s up to you to define that in your project proposal.
I expect that 350 hours will be needed because btrfs is quite a complex filesystem.
1 Like
After reading through the entire btrfs codebase, here is what already works and what is missing:
What’s done :
BTree COW, transactions, ExtentAllocator, Inode CRUD, directory ops, WriteSuperBlock and ReadAt
What is missing:
- BTree node split and merge - MakeEntries() hits B_DEVICE_FULL with only a TODO, and RemoveEntries() hits B_DIRECTORY_NOT_EMPTY with only a TODO, without split/merge any write that fills a leaf node will fail
- WriteAt() is completely absent from Inode.cpp - needs to handle both inline extents (small files) and regular extents (larger files) via ExtentAllocator::AllocateDataBlock()
- File creation (fs_create) is NULL in the vnode ops table - needs btrfs_create() calling Inode::Create(), Insert(), MakeReference()
- File shrink/grow is stubbed - btrfs_write_stat() returns B_NOT_SUPPORTED for size changes, needs truncate support
- Volume::Initialize() is incomplete - extent tree, chunk tree, fs tree initialization not done, mkfs effectively does nothing useful after writing the superblock
- B_DISK_SYSTEM_SUPPORTS_WRITING is commented out - volume is hardcoded read-only in Mount()
- free_blocks hardcoded to 0 - needs NumFreeBlocks() from ExtentAllocator
- Attribute writes all return EROFS - btrfs_write_attr, btrfs_create_attr, btrfs_write_attr_stat, btrfs_rename_attr, btrfs_remove_attr all stubbed out
Scope and my proposal: (350 hrs should be sufficient imo)
Core deliverables:
- BTree node splitWriteAt() for both inline and regular extents
- File creation and basic truncation
- Removing the read-only restriction
- free_blocks tracking via NumFreeBlocks()
Stretch goals: (if time allows)
- BTree node merge - tree stays valid without it, only becomes inefficient after heavy deletion
- Volume::Initialize() completion - can be bypassed by using Linux mkfs.btrfs for testing
- Attribute writes - first lets focus on testing basic write operations
- DUP/RAID support in ExtentAllocator - single device testing for now so meh
5 Likes
Ahoy Anuj !
Welcome in Haiku Archipelago, have a joyful coding surf at GSoC 2026 with us !.. 
Extending filesystem availability, capabilities are highly welcomed here.
The more is the better ! 
1 Like
Hi,
I’ve put together a draft proposal for the btrfs write support project. Would appreciate any feedback before the final submission.
Thanks
@PulkoMandy Hello !
I’ve given you comment access on both btrfs and complex font doc
Please comment whenever you are free