Ted Ts’o sent out the EXT4 updates today for Linux 6.11. He explained in that pull request:
“Many cleanups and bug fixes in ext4, especially for the fast commit feature. Also some performance improvements; in particular, improving IOPS and throughput on fast devices running Async Direct I/O by up to 20% by optimizing jbd2_transaction_committed().”
I really like the idea of BTRFS and what it can do. For my recent system, build in end of 2023 (not a year ago) I really thought about and compared the systems, but end up using EXT4. Here some thoughts I had:
I want to use BTRFS as my main system FS, but I wasn’t sure which alternative FS to use (there are other contenders too), if I need the extra functionality, if its 100% stable for me on a non Fedora system and I also did not want to spent the time learning and experimenting with it, yet. But I will. And if other distributions I install or boot into would work well with BTRFS, if they are not on the newest Kernel yet.
I’m not quite sure why people are still worried about the stability of btrfs when it has been rock solid for years. Synology has been using it for quite a while now in their NAS systems, they surely wouldn’t if it’d mean a lot of customers were at risk of losing their data.
There are valid reasons not to be using btrfs (although I’d argue most ordinary use cases don’t have a valid reason), but stability certainly isn’t one of them, independent of the distribution used (unless it’s ancient).
Note my research of BTRFS is almost a year old now. And there was still a few headlines making round of problems with BTRFS in some cases. A controlled NAS system is not the same as random user configuration of a random desktop user. And as said in my comment, I was not sure if it would be stable for my installation (when I did my research) and did not claim it to be unstable. On the other side, I know for a fact that EXT4 is stable and I did not research more or experiment to find out which one is better for me.
Current state of BTRFS: https://btrfs.readthedocs.io/en/latest/Status.html (note when I did my research, Linux was at Kernel v6.4, therefore BTRFS was in a worse situation than today)
Wait til your table with all the checksums gets messed up on an “older” btrfs install. Happened to me on a VM because I didn’t know copy-on-write should be disabled for large frequently partially updated files. It also slowed that VMs IO down a lot.
Like most file systems, BTRFS is great if you know the edge cases. I recently moved to ZFS on my new work system, which has been a great change in terms of in-line snapshots and the like.
If EXT4 meets your needs, that’s awesome. If you understand how to use a different FS well or are willing to learn (and risk), I would also encourage other options as well.
Because of widespread fearmongering, itself caused by the filesystem taking too long to become stable and garnering a bad reputation as a result which it has never shaken off.
If you’re interested I have a fairly thorough “I use this” post on my website (last time I updated it was in early 2023) about btrfs.
Sure! I’m interested into the “current” state or real world experience of it. Wouldn’t mind if you post it here. Although I am not sure how relevant it is 1 year later, because the filesystem is quite under development.
Here you go: https://drwho.virtadpt.net/archive/2019-11-04/experimenting-with-btrfs-in-production/
That its under development means that it’s being maintained. EXT4 is still being developed, so is xfs. And the other ones that are fairly popular, for that matter.
Thanks. But it’s important to note your experience report is based on the experience of 2019 and the slight edits aren’t changing that. That its being developed is not the same as under maintenance. EXT4 is fully developed and there are only optimizations in performance expected, if anything, while BTRFS still needs active development to improve compatibility and some other features.
I’m still curious to how to work with it and such a report is still welcome. I’ll give it a read. Edit: Hopefully my reply didn’t sound too negative. I’m interested in the process of going all of this, so the article is useful in a practical sense.
@thingsiplay @drwho , as soon as RAID5/6 is fully ready (and I am aware it looks like it’ll never be), I’ll be switching over to it.
What’s your use case? Do you need the storage capacity and parity of RAID-5 or -6? The write performance?
@drwho I have a data server with data I hold dear and want to ensure losing drives (using RAID6) won’t lead to me losing my data.
That’s entirely fair.
My experience is based on running that btrfs array since 2019. It’s still running in production on my server, I still use it daily, and the data I keep on it is still accessed, processed, indexed, and backed up every day. It’s not an experiment for the sake of a blog post, it’s a thing that is part of my personal infrastructure. The reason I update that post periodically is because I learn something new, or something minor has changed and the text should be updated to reflect that. If using btrfs on a busy server every day is the experience of 2019, I don’t know what to say to that.
Oh that’s hugely different then. It was not apparent that you were using this setup since the initial blog post. Maybe make a note at the top of the post, so your message (like here) is understood. Don’t get me wrong, I appreciate the clear information you give here and your feedback on how this works. From your report and given its the default FS for Fedora, its absolutely clear that I need to review my bias and view as BTRFS as a contender for my next system drive.
I had intended that the dates on the edits would have suggested otherwise (the last was 20230422), but I also get how easy it is to miss them if you’re looking for something specific. I can’t change the publication datestamp because that’s part of the slug, and it would break links both internal and any that are external.