I found ext4 much faster than btrfs for the file system with external ssd
Posted by SolDirix@reddit | linux | View on Reddit | 92 comments
Posted by SolDirix@reddit | linux | View on Reddit | 92 comments
natermer@reddit
Yes XFS and Ext4 are, in general going to be faster.
For common desktop use the main benefit to using BTRFS or OpenZFS is going to be that it has the ability to scrub the file system for errors. But without a second device to be mirrored (or more drives with different RAID-like schemes) you really can't do anything about it.
I really only bother with COW file systems if I have many drives in a system.
For common desktop setup having a single big partition formatted XFS or Ext4 is the way to go. Simpler, faster, easier to recover.
If you are worried about data protection you need to be using backups. Trying to tackle it at the FS level isn't going to work.
rmyworld@reddit
This is one of the main reasons I keep using Ext4 as well. For most of my devices, I only have a single SSD where all the data lives. If ever the SSD starts to fail, I'm pretty confident I can
dd_rescuethe device and rune2fsckto give me back all the remaining intact data on the filesystem. If the filesystem is unrecoverable, I can usephotorecto read any data that hasn't been overwritten.I'm not sure if I can do all that with Btrfs.
dthdthdthdthdthdth@reddit
With btrfs you can use snapshots and btrfs send to make proper backups and due to checksumming you can be sure you're data is not corrupted. If you care about your data this is what you want. If you don't, being fairly confident to be able to recover parts of it is good enough. I use ext4 for external drives that just hold data temporarily, or for system drivers if I can easily recover and don't need snapshots, or for data that is backed up on some other level. But for a typical desktop system putting everything in one btrfs system is usually best if you care about safety of some of the data. Slightly lower performance rarely matters when you have fast ssds.
int23_t@reddit
The main benefit for me is filesystem level compression cause otherwise my data doesn't fit my drives, last time I checked compression saved me around 350GB on a 1.5TB system.
(also I have two drives one 1TB one 512GB so I do keep at least the important stuff in my home partition safe that way, but I do have backups on my homeserver and phone too so doesn't really matter...)
lemmiwink84@reddit
I only use btrfs for the OS itself. For gaming partitions I use XFS, for everything else I use EXT4.
btrfs is great for making sure you have snapshots, being very space efficient etc, but for raw speed it’s not as good as EXT4 or XFS.
RazerPSN@reddit
Does it really make a difference? I debated for long on what to do, in the end i just installed games on BTRFS
lemmiwink84@reddit
I can tell the difference loading World of Warcraft. Apart from that, I haven’t seen any difference, or rather noticed any difference between XFS and btrfs.
JeSuisAnhil@reddit
Any particular reasons for using XFS over ext4? I'm planning to migrate my gaming PC to Linux this October (currently on Win10 with ESU), still undecided on the exact setup. I was thinking of using Btrfs for two reasons:
$HOME.I guess I could just use a bind mount for the prefixes.
Daktyl198@reddit
XFS is the fastest filesystem according to many benchmarks, so in a situation like gaming where speed matters it’s good to have.
Kuipyr@reddit
Does it really though? I don’t think games are pulling that heavily from disk after initial load to the point where filesystem matters.
Daktyl198@reddit
Smaller indie titles or older games, no. Modern games (especially those that utilize the windows DirectStorage API) do quite a lot of streaming from disk while the game is running, and/or save writes.
But beyond the speed, it’s an extremely stable filesystem with a few bonus features over ext4. Between the 2 I’d pick XFS every time.
faramirza77@reddit
You also don't run out of inodes like you often do on poorly created ext4 partitions.
rabbit_in_a_bun@reddit
Traditionally, XFS was better for a few large files and EXT4 was better for many small files. My backup drive with my photos and videos is XFS.
YouRock96@reddit
Seems like overthinking of FS, I'm not sure it's really that justified on a practice
rabbit_in_a_bun@reddit
Traditionally means $time ago... I just haven't re-format them since.
RogerGodzilla99@reddit
what is your definition of 'large'? things that take up multiple blocks, things that are multiple gigs, or...?
rabbit_in_a_bun@reddit
Yes. Imagine a video library as a good example.
RogerGodzilla99@reddit
I'm asking where your cutoff is for 'large'.
rabbit_in_a_bun@reddit
Everything from 100mb and up. EXT is best for millions of files under 1mb
RogerGodzilla99@reddit
gotcha. thanks for clarifying!
Kitayama_8k@reddit
FYI btrfs setups typically don't snapshot home because you end up in a situation where deleting files doesn't clear space until you while out all your snapshots of the home subvolume.
If you wanted to do this, maybe you would create a new subvolume, mount it to your save folder, move the contents in, and configure that to snapshot every 20m or something,
JeSuisAnhil@reddit
Thanks for bringing this up, that's something I didn't even think of. A separate subvolume specifically for the saves does sound like a nice idea.
Kitayama_8k@reddit
I think a cron job to back up the file would be significantly easier.
JeSuisAnhil@reddit
Why, though? Seems like about the same amount of effort to me.
Snapshotting the prefixes entirely is something you set up once and forget. Backing up the file(s) is the same thing, but you have to set it up for every offender.
Kitayama_8k@reddit
I mean you would have to set up snapper, time shift, or a cron/systemd job to snapshot the subvolumes, and manually create subvolumes for every new game, move the files out, into a new subvolume. If you put steam on a subvolume, you will get no space returned from games being removed until you delete all your snapshots.
The benefit of btrfs snapshots is not that you can copy a folder, which is basically what a snapshot is. The benefit is the that the copy of the folder takes up only the difference in space as those folders change after the copy. But the only file you want to preserve is the save file which is changing, so just back that up with a normal copy task to a backup folder, it's gonna take the same amount of space, unless I'm missing something about how save files work. You might even be able to automate it with rsync or time shift rsync more easily than with chron or systems.
JeSuisAnhil@reddit
I assumed that the games themselves aren't stored within the prefixes, is that not the case? The directory itself is called
compatdata, so I thought it's just a fake driveC:for the games to store their saves and settings.lemmiwink84@reddit
Nah, just that it gets a lot of attention on linux 7.0 kernel. Also haven’t tried it before a couple months ago.
Do I notice any difference over EXT4? Not really, but the self healing in 7.0 and the tests in speed vs EXT4 looks like it has a bit of a benefit.
tjj1055@reddit
dont speak truth, you will be downvoted by the clueless linux fanboys.
dddd0@reddit
A CoW FS does more inherent work than a journaling FS.
rustvscpp@reddit
It absolutely is inferior to ext4 for raw speed. For simple personal computer setups, ext4 is the better choice.
herd-u-liek-mudkips@reddit
I very strongly disagree. If your precious family photos get corrupted on disk on ext4, then you have no way to detect that automatically. If you take automatic backups (and you do, don't you?) then ext4 will happily let that corruption be propagated to your backups, and you'll be none the wiser. BTRFS, on the other hand, won't allow this. I think that it's exactly the simple personal computer use case where BTRFS is better for this reason, because raw throughput is usually not that important if it comes at the cost of nearly nonexistent data integrity constraints.
rustvscpp@reddit
I have never once experienced corruption on ext4 that a simply fsck couldn't fix. On the other hand, I've had multiple catastrophic failures with brtfs. Ext4 has a much better track record for reliability.
herd-u-liek-mudkips@reddit
That you know of. Ext4 does not detect corruption and will let you carry on with corrupted data, so one would expect corruption to go undetected on ext4. Sorry to be so blunt, but honestly I wouldn't even consider any notion of track record here unless it accounts for the fact that BTRFS will loudly refuse to read corrupted data while ext4 will read it silently, which can make BTRFS seem more prone to failure in comparison than what it actually is. I would also expect any comparisons to be made only for the span of time where BTRFS is no longer considered experimental. When these things are taken into account, I would be surprised if ext4 actually came out on top in reliability. Ext4 has its strengths, but I don't believe that data integrity is one of them.
Coldkone@reddit
Ext4 does not have compression. The built-in btrfs compression is one of the biggest pros about btrfs in my opinion. Btrfs default zstd almost halves my SSD usage. This reduces SSD wear, since less stuff is written to the memory cells. SSD has limited write-cycles, which many don't know.
I would much rather take this than have bit more speed with XFS or EXT4. Modern SSDs are very fast anyways to notice the difference as a normal desktop user.
pppjurac@reddit
Meh, this endurance fear drags since early 2010s. 99% of consumer drives will held way more than any part of gear and more than single machine. Even for basic drives, their TBW rating is so high it is not even a deal anymore.
You are "high volume" user ? Get a better SSD with big TBW and stop worrying. I reused 2nd hand server SSDs with multiple 100s of TBW but that is still only 30% of what Micron guarantees they are capable.
Also what most of consumers put on ssd in mass are media files - mp3/flac/avi/mp4 and such which btrfs compression will not work on.
For consumer today, wear is not a issue anymore.
sapphic-chaote@reddit
I assumed this would be true until I benchmarked. It it turns out some (not all) games are surprisingly compressible; Valve games often compress to 40% of their original size. Binaries also compress well. It doesn't matter too much if you're storing a few TB of video, but for me was very noticeable.
NoTime_SwordIsEnough@reddit
It's insane how many games are easily-compressable, even using NTFS compression on Windows.
Worst case I've seen was a Unity Engine game that was like 4 GB on disk, but SOMEHOW compressed down to a mere 200 MB with transparent FS compression. But otherwise, your 20-40% average savings is very accurate from my experience.
Coldkone@reddit
Is you have a lot of data on your drive, btrfs definitely helps. I game on my machine and it's actually insane how much less data my games take with btrfs compression. Modern SSD drives are more durable than ever, but Btrfs can still massively increase the lifespawn of SSDs.
I think that Btrfs pros weight more than its cons by a huge margin. Ext4 in other hand is very basic, old and lacks modern-day file system featues, like multi-level compression, COW, file-corruption healing with RAID configuration and checksumming. Btrfs is also excellent as archive filesystem, because it can detect bit-rot.
necrophcodr@reddit
Which does require multiple drives to work. Fixing bit-rot requires duplicate data. It's very nice to have Btrfs be able to do this on the file-system level, which solves a whole host of issues that hardware and software RAID does not, but most consumers won't have the hardware for this.
Coldkone@reddit
True. It takes work to get all these possible BTRFS features enabled and working (especially the RAID configs), but its still nice that I have these features built-in in case I need them.
necrophcodr@reddit
I don't personally think it takes a lot to get self healing working with Btrfs, but it requires you to have the hardware ready for it, and to intentionally do this. Most people never will.
Slight_Manufacturer6@reddit
I consider snapshots to be the best feature.
MarzipanEven7336@reddit
Hmm, 🤔 glances down, 27GB/sec R/W, glares back to screen, not.
matsnake86@reddit
Did you try xfs?
BTRFS Is packed with a lot of features which must be configured. Not really suited for portable drives.
bunkbail@reddit
https://www.phoronix.com/review/linux-612-linux-70-xfs-ext4/7
ext4 performance is so close to xfs these days that I wouldn't bother with xfs unless you really want to squeeze out every last bit of performance. you can't shrink xfs partitions, so using ext4 gives you that flexibility if you ever need it.
thefossguy69@reddit
I was happy with ext4's performance but switched to XFS out of necessity because my /nix/store had so many files that it ran out of inodes. XFS has dynamic inode allocation, whereas ext4 hardcodes it at the time of filesystem creation. And just yesterday I discovered XFS project quotas that are-in a way-similar to ZFS datasets for my use case of having dynamic yet still capping partition size.
faramirza77@reddit
This is why I dropped ext4. Inodes getting chewed up.
bunkbail@reddit
oh yea i didnt think of that. nix is a big one, but i could see im having the same issues with build caches (ccaches), mesa shader caches, docker layers or even git objects. so far im yet to hit the "ext4 inode wall".
NoTime_SwordIsEnough@reddit
XFS also has extent-sharing, so it can also be copy-on-write in some ways. It's very useful for creating instant backups of directories with many GB of data, without using up double the space for those backups.
Note tho that it's distinct from mere hardlinks, because once you write to such a file with shared extents, you modify a copy of the extents, just like btrfs.
Moscato359@reddit
Ext4 has no data protections at all
Atleast xfs will protect metadata
lebean@reddit
Thankfully we all regularly backup our data, right? Right?
Moscato359@reddit
Actually backups won't save you here
You get silent corruption, and your backups will contain the corrupted data
GinormousHippo458@reddit
I haven't desired to shrink a volume since 2003, grow only.. With LVM, trimming and sparse over provisioning, shrink is now pointless.
And, I came here to say BTRFS is a fat pig, slow, complicated trash heap, much to dangerous to store a critical byte on. I've tried it over the decades, always ending in frustration and tears.
amarao_san@reddit
I tried. They deprecated xfs v4 without an upgrade path (except for volume re-creation), so, nope, goodwill is lost.
NeuroXc@reddit
I found several serious performance edge cases on btrfs, especially when working with large files. Xfs is the way.
SuAlfons@reddit
umm...yes.
You use btrfs for features, not for speed.
Dynamic subvolumes and snapshots. If you don't need those, use ext4.
RoseBailey@reddit
Yeah. Btrfs is slower. The reasons you might pick it anyway are that it has copy-on-write, filesystem-level compression, subvolumes, and snapshots.
It's a speed vs features tradeoff.
proton_badger@reddit
I pick it for the data checksumming, silent corruption may be rare but it's scary. But I use it on an NVMe SSD so I don't really notice any practical speed difference from ext4, for my use (games and dev).
Ok-Anywhere-9416@reddit
Btrfs can be great for external disks too if you know what to do. But yeah, ext4 and XFS are just very quick by default.
https://gist.github.com/braindevices/fde49c6a8f6b9aaf563fb977562aafec
and https://github.com/Toliak/hdd-fs-benchmark
NeatRuin7406@reddit
ext4 being faster than btrfs on external SSDs is a pretty common finding and it makes sense when you look at what btrfs is doing differently. the copy-on-write semantics in btrfs mean every write potentially triggers a metadata update cascade -- block groups, checksums, tree nodes -- and that generates more random write IOPS than ext4's simpler journaling approach. on an external SSD over USB you're already bandwidth-constrained and adding more metadata overhead makes it worse. the real question is what you're trading for that overhead. btrfs gives you transparent compression, snapshots, subvolumes, and checksumming. if none of those features matter for your workload then you're just paying the cost without getting the benefit. for simple external backup storage or scratch space ext4 is usually the right call.
Slight_Manufacturer6@reddit
Of course it is faster, it doesn’t have all the features of btrfs. You seem to be missing the point of the file systems. Use the right file system for the right use case.
Moscato359@reddit
Btrfs has reliability benefits
Its not meant for speed, its meant to not destroy your data like ext4 is so, so prone to
j-dev@reddit
CoW is nice to have. I’ve never heard it said before than EXT4 will destroy your data. XFS combined with wirb power loss is another story.
LEpigeon888@reddit
Ext4 will not destroy your data, your drive will, and ext4 can't prevent it. Btrfs checksum the data, so if your drive has a faulty bit, you'll bit notified.
necrophcodr@reddit
It won't fix it without backups or having redundancy via more than one drive, though. You also won't be notified if your root partition is Btrfs and this volume has checksum issues. Btrfs will instead fail to mount it, with the recommended route being to NOT fix the issue using filesystem checks like ext4 does, but to instead reinstall the entire system or restore from a backup.
Moscato359@reddit
You actually can dupe data with btrfs on a single drive
It just eats half your disk space
HunsterMonter@reddit
If your drive starts failing, Btrfs can notify you before serious damage is done, whereas ext4 will silently accumulate errors. Imagine for a moment you go to open up a file and it's inexplicably corrupted. You go check on your disk and you see it is failing, but since you used ext4, you don't know what the extent of the damage is. Even if you have backups, you don't know what files are safe and what files aren't, and you don't know how far back you need to go to find a safe backup.
Moscato359@reddit
With duplicated data, it can stop the corruption from staying around
EvaristeGalois11@reddit
This is what I'm going through right now.
My external HDD is spewing reading errors left and right and the smart values are dropping alarmingly.
Many files are getting corrupted but I have absolutely no way of knowing which ones are the corrupted and which ones are still intact to salvage.
Moscato359@reddit
I have seen many, many, many ext4 corruption incidents professionally just due to the size of data
Stopped using it, and replaced it, and haven't had any since
VirtuteECanoscenza@reddit
They are referring to bit rot. Ext4 fails immediately with that
Sent1ne1@reddit
Yup, I was using ext4 until I started having disk corruption caused by some LVM caching bug - by the time the corruption was noticable, ext4 was usually so gone that I had to format & restore from a backup.
I switched to btrfs, and it warned me immediately after the tiniest corruption. I was able to repair that (delete & restore the corrupted file) & have a working system again.
I no-longer trust any filesystem without checksums. In this regard xfs is infinitely superior to ext4, so I'll probably switch from btrfs to xfs for storing backups.
EvaristeGalois11@reddit
i don't think xfs has checksums for file contents, but only for metadata like ext4.
donut4ever21@reddit
And the sun rises from the east. lol. Yeah, that's very known that ext4 is faster than btrfs. For me the only benefit btrfs has is the snapshots. That's why I only have it on my root partition and everything else is ext4
throwaway234f32423df@reddit
Without checksumming, you have no idea whether your files are intact or damaged. I think it's worth the overhead for the peace of mind.
JohnyJohn92@reddit
No one cares about raw sequencial speed on desktop computers ever, very rare corner cases when you back up entire drives, otherwise you are network speed limited or processing limited. Infuse btrfs and I forget about nonsense between filesystems, redundancy and features are more important than ever rather than 10% extra raw speed you won't even feel .
ClubPuzzleheaded8514@reddit
Of course, it's documented for a long time. BTRFS doesn't aim to be fast, but restorable.
ranjop@reddit
I think XFS is still faster. Yet, the COW snapshots of Btrfs are just pure gold for many storage related tasks (backups, rollbacks).
TheTaurenCharr@reddit
I think these distributions should give the user some context and options regarding the choice of filesystem.
I would definitely install ext4 /root and /btrfs home, and I guess that's what Fedora does already, no? That should work great on an average machine, especially when we rely on backup tools. However, if the user isn't interested in btrfs related features, then having the entire installation on ext4 is a proven method, working quite well.
nostril_spiders@reddit
Fedora defaults to ext4 for /boot and btrfs for root. If you create a separate /home, it defaults to btrfs.
That's for 43. Iirc, it was thus back to 39.
TheTaurenCharr@reddit
Yes, I meant to write /boot, not /root. Editing my comment.
TomB1952@reddit
The speed of BTRFS is debatable. On a fast, lightly loaded,system it's said to be faster than EXT4. On my system that goes for many hours at a time at 95+% CPU on all cores, EXT4 is considerably more responsive.
My testing was just a brutal script that used "timex" to time a bunch of copies.
BTW, when the system is not under load, they seem about the same. Sometimes one wins, sometimes the other wins. This, when using the same simple test.
Add in the fact that I can only restore from a snapshot 50% of the time and it's EXT4 with timeshift for me.
Diuranos@reddit
Ext4 Lower overhead on the CPU and it’s still being developed, while with Btrfs I don’t really hear much about updates to that format. I have Bazzite OS and my main drive is Btrfs, but all my other drives are ext4.
superboo07@reddit
btrfs is definitely still being developed
FryBoyter@reddit
https://btrfs.readthedocs.io/en/latest/Feature-by-version.html
As a source for this statement.
Diuranos@reddit
Good to know. :)
int23_t@reddit
btrfs is not a filesystem for raw speed. It's for checksumming blocks so you know your problems, zstd compressing your files so you get 20-30% more space out of your disks(and 20-30% more throughput if your bottleneck is the drive not the CPU), making sure you have snapshots if you fucked something up, and allow you to create subvolumes as mount points which allow you to do things like distrohopping without repartitioning.
EatTomatos@reddit
If you have live compression enabled for btrfs, then the first time you write stuff it takes time to compress. Then btrfs has always had issues with it's memory management. A lot of it has been ironed out, but it's also less scalable than other FS's. ext4 is faster but will slow down due to atime. xfs can be similar or even faster in some cases. And then if you wanna go ultra modern, a ZFS system will have some of the fastest IO due to arc using your ram for the IO. However then you have to learn how to use ZFS if you want to make ot scalable.
Evil_Dragon_100@reddit
This is first time i heard that zfs is performative claims. I like zfs to but too bad can't do swapfiles with hibernation in it.
tesfabpel@reddit
Technically, btrfs has some quirks about swap files (but the issue is the swap system that's very picky)
https://btrfs.readthedocs.io/en/latest/Swapfile.html
basically, it seems like it wants a file that has a direct and raw mapping to a disk's address space (I may be wrong here, but probably DirectStorage or an eventual Vulkan implementation needs something like this as well?)
pantokratorthegreat@reddit
xfs is even better.
BabaTona@reddit
xfs may be even better.