Don't forget: buggy filesystem code can easily lead to catastrophic data loss, which ruins your filesystem's reputation.

Lines of code isn't the only important metric. A project with a smaller number of LoC can take a long time to fully test and debug and validate.

Hammer2 comes to mind as well..

Does it run on Linux or ordinary BSD? Does any company use it?

I'm sorry, as I keep hearing these criticisms around BTRFS, I still don't know why. What is so messy about it? Honest question

Have you tried reading the code? It's twice as large (107KLOC) as ext4 (45KLOC), where ext4 is viewed as a natural evolution of ext2 (7KLOC).

45KLOC of C code already sounds really scary to me, although yeah, journaling is really nice to have.

Yes, that's scary. Understandable, but it does come with a lot of functionality that's nice to have no?

It's "perpetually half-finished". Bad track record with reliability and loss of data, lots of stories on the internet. It perhaps got better, but RAID5/RAID6 for metadata (standard use of disks) still not oficially recommended and thus standard RAID5/RAID6 is not reliable. Also, look at some FS benchmarks - BTRFS is still much slower than EXT/XFS, and slower than ZFS.

About the only class of scenarious to use BTRFS instead of ZFS is if you want the features, do not need RAID5/6, require support by Linux distributor/kernel developers or for some other (hard to think of) reason you can't use ZFS.

Thanks, that makes sense. I should look more into it

No problem. For more, this looks like a good intro

https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...

Filesystems aren't complex to implement -- even complex filesystems.

What's harder is making them as robust as they need to be for practical daily use. Doing that is a matter of comprehensive testing, though. With filesystems, the hard part is QA, not implementation.

Oh it's word games with "implement". OK then, let's agree then developing a modern filesystem into a robust software for practical daily use is hard.