BTRFS or EXT4 for data HDD?

Hi folks,

After doing a little self-research, I've found out that at a distance of approximately three feet, I can't discern the difference between 720 and 1080 dpi videos streaming on a 22" monitor. So I'm going to install Garuda to my desktop, which has a 128 GB SSD for the OS & applications and a 1 TB 7200 rpm HDD used for data storage. I already have Garuda dr460nized running on a laptop which has only one drive w/BTRFS. I'll put KDE Barebones on this machine.

Garuda in BTRFS will be on the SSD on the desktop machine, but I was in a quandary about the filesystem to use for the 1 TB HDD which will contain only data. I remembered reading a while back that BTFRS was slower than EXT4, but I don't experience that on my laptop because, I believe, the optimizations implemented by Garuda's developers have perhaps overcome any noticeable differences in daily hobbyist use, running mainly applications.

So I did a little digging and reading, and the latest article on Phoronix delves into real world testing of BTRFS, EXT4, and other filesytems on kernel 5.8, which is the latest testing article I could find. It appears, in conclusion, that BTRFS is slower on application launches, maybe slightly ahead of EXT4 overall, and perhaps a bit better in read/writes, the bits I was most interested in reading, since we're talking about a 7,200 rpm spinner for my data drive, which is decent for a desktop machine.

So my conclusion is it probably doesn't make any "real" difference, since my data changes are few and won't impact video streaming, reading the news, or haunting you folks over the internet. So I'm going to format this HDD in BTRFS, just for the sake of consistency and because BTRFS is new-to-me, I've been researching it, and want to learn more about it.

I'll report back if my in-use conclusions differ.




The other useful feature of BTRFS is compression, though that won't make much of a difference if you're mainly storing media files.


LOL, I had forgotten about that in the confusion of trying to understand mountpoints in BTRFS. :wink:

It will make some difference, depending on the aggressiveness. Documents, yes, but they're small by nature. It does a surprising job with photos and music, I've noticed. Not so much ISOs and MP4s. That's with standard ZIP compression, so it ought to make an interesting comparison.

Thanks for the reminder, Jon.


If you're going 'irregular' on your filesystem, why not XFS for your spinner? Everything good about btrfs is there, plus robustness for your data....

YMMV :grin:


There's nothing irregular about XFS, it's older than ext4. :grin:

1 Like

True - but not always... ummm... accessible? Freely, anyway :grin:

I've been an ext(2,3,4) user all along, but am contemplating f2fs for the NVME drives lately, just to skip the journals' extra writes... (let alone COW)

What about ZFS?

Also good for spinners (maybe best?) but I don't like COW or journalling on SSD-based drives. I also don't know enough, or have testing facilities to do more than replay others' opinions! as far as I understand it, XFS=Silicon Graphics, and best at big files and parallel access - ZFS=Sun, and best at more general tasks. FWIW.


I have read countless opinions on BTRFS, CoW, etc. on SSD drives. My consensus is perhaps that they were detrimental to some of the earlier SSDs (but not all), and that most modern SSDs are now far less susceptible to deterioration. Of course, I do not have any anecdotal data on my one, relatively new, 128 GB M.2 SSD to know one way or another. I suspect "they" may be right, but I remember how CD/DVDs would rot away, when they were originally touted for some huge lifespan as storage media.

Thankfully large SSDs are inexpensive enough for some folk's budget to experiment with them--just not mine.


I'm a big fan of ZFS. Hasn't let me down so far, has all the features, combined with sanoid (and syncoid) is trivial to configure with incremental automatic snapshots and backups, and has been more reliable than btrfs for me.

(Just deleted a file? No worries, just navigate to $USER/.zfs/snapshots/ and find an older version. Easy.)

With ZFS 2.0.0 you can now also very easily add an SSD as a persistent cache device (L2ARC) for a spinning disk, massively improving data access speeds (so a bcache equivalent, natively supported by the FS, with zero faff).


recently I discovered bcachefs. It seems like a frankenstein filesystem, as it states to have all of the features of other advanced filesystems.

1 Like

Given bcachefs is an evolution of bcache it end up being a replacement for btrfs at some point.

1 Like

I have read the Arch Wiki about BTRFS, and its features make it much more secure than EXT4.

It is my first installation with BTRFS. The servers that I administer mail and web have XFS. And my ex linux was always EXT4.

I don't feel a degradation in my latoop with Garuda, quite the opposite. Compared to Manjaro XFCE, Garuda Plasma is much faster.

What I do think is that I should do more documentation on how to manage the BTRFS file system, for when I need to make changes (such as adding disks, removing them and using BTRFS own features, which now I don't know how to implement).
I would need to find a bibliography for it.