Just a simple question : Which file system do you recommend for Linux? Ext4…?
EDIT : Thanks to everyone who commented, I think I will try btrfs on my root partition and keep ext4 for my home directory 😃
btrfs every day of the week. The only scenario where I’d even consider something else is for databases that would suffer from CoW.
I’ve been running it on my home server since 2010. The same array has grown from 6x2TB to 6x4TB, one disk at a time as they’ve failed. Currently sitting at 2x18TB+1x4TB. No data loss even though many drives have failed.
For standard use, ext4. If you want to tinker and use fancy features, btrfs (or maybe zfs?).
I don’t know what’s the brand neW meta pick, but at least BTRFS over Ext4. BTRFS is just more stable and less corruptable than Ext4. Heck, fedora changed to it as default
To be fair, Fedora switching to something as default isn’t a good sign that you should start using it. I do agree, though, btrfs has come far enough to be a default choice for most people.
What did fedora adopt that wasn’t a good choice in hindsight?
PulseAudio?
Honestly, unless there’s some specific thing you’re looking for just use your distro’s default. If your distro doesn’t have a default I’d probably default to ext4. The way most people use their computers there’s really no noticeable advantage to any of the others, so there’s no reason not to stick with old reliable. If you like to fiddle with things just to see what they can do or have unusual requirements then btrfs or zfs could be worth looking into, but if you have to ask it probably doesn’t matter.
- Note that ext4 is damn old and thus also not as performant as more modern ones like btrfs or bcachefs
- BTRFS if your distro configures it well
I think BTRFS is even good if you dont even use its features. But you should use them, like snapshotting your filesystem before every update.
I personally dont use any features manually though, as Fedora Kinoite does that for me.
2008 is not “damn old”
Exactly especially when the default file system on windows is 30 years old.
It is 16 years ago, that’s pretty old in terms of technology.
It’s also an evolution of ex3 and ext2, and ext if you want to consider it’s very short lifetime. In fact, the lead developer stated in 2008 that it was meant as a stop gap, as it’s based on old technology with some new features, and that BTRFS was the future.
And yet here we are 16 years later with btrfs only just in a position to be usable (perhaps. My experience is that I’ll never use it again)
Note that ext4 is damn old
Hmm ? Linux kernel is way older than ext4. And before ext4 there was ext3 and ext2. Linux users also have the choice of using XFS file system and for IT persons working for corporations XFS can have some advantages. Let’s see, XFS was born in 1993.
more modern ones like btrfs or bcachefs
Years ago I thought that bcachecfs looked interesting but last thing I read about it this year was not very promising regarding reliability. Not sure whether it was in comments on Lemmy but here I found something from Linus himself : https://en.wikipedia.org/wiki/Bcachefs#Stability
Yeah, bcachefs is still very very young, and not ready for much of anything beyond tinkering. But I’m definitely excited to have a native filesystem that’s designed with tiers in mind.
Note that ext4 is damn old and thus also not as performant as more modern ones like btrfs or bcachefs
This is not true. BTRFS has more features but ext4 is very performant. They’re both similar enough that I promise you that you wouldn’t notice unless you had some very specific use-case that needed to be performance tuned.
What do you think “being old” has to do with performance?
What do you think “being old” has to do with performance?
Being tailored to NVMEs or SATA SSDs instead of to HDDs and similar. But I am not sure about which one would be better here.
Phoronix Benchmark so we have something to look at
BTRFS seems to be better at multithreading, being outperformed by F2FS (which I forgot to mention, it is used on Android and I would call that damn stable).
Actually, F2FS seems to be a really good replacement for EXT4, being top in most tests, while having no journaling, while BTRFS in fact worked pretty badly!
Right, your claim that ext4 “isn’t performant because it’s old” is crap.
I’ve always used XFS on spinning drives and F2FS on SSDs. No issues, they’re very solid
So i normally go with ext4, however windows can’t really access ext4 drives so you’d need to find a file system that both support if you want to access the drive/partition from windows. My drive with all the games is ntfs for example which works in Windows and Linux. (At least for normal storage, idk if you can boot linux from it although i wouldn’t see why not)
NTFS can’t handle Linux file permissions. It is not suited as a system drive.
And supposedly it can give you problems if you use it to store your Steam games. I never cared to test that, though.
NTFS can handle Linux permissions perfectly. In fact, many Linux filesystems lack the kind of permissions that NTFS does support, not the other way around. FAT doesn’t do permissions, but NTFS has supported decent (“extended” for Linux filesystems) permissions since the mid 90s, i believe even since before Linux even existed.
The NTFS driver on Linux isn’t very good or fast, so I’d avoid NTFS for a system drive for sure, but as a filesystem, NTFS is fine. It also doesn’t help that many distros don’t ship the modern NTFS driver in the kernel, so booting off NTFS doesn’t work in many cases.
Wsl2 lets windows do ext4
There’s also an open source BTRFS driver for Windows.
BTRFS &/OR EXT4
ext4, just keep it simple.
If you don’t actually have an opinion, just go with the default, ext4 really is a very good file system, but if you want to have an opinion and not go with the default, zfs is truly a fantastic file system.
In my opinion, it depends. If a distro has BTRFS configured to automatically take a snapshot when upgrading (like OpenSuse Tumbleweed), then BTRFS.
If not, for a beginner, ext4 + timeshift to take snapshots of your system in case an upgrade goes wrong will be fine.
But you can also just use BTRFS without any fancy setup and not use its features, it will still be faster.
Btrfs is slower than ext4, xfs, and f2fs in pretty much every metric. Noticeably slower app opening times is the reason I switched to F2FS for good.
Edit: BTRFS has advantages that likely make it better for me.
It has compression and allows flexible partition sizes. The compression may explain the speed decreases.
Compression might be useful in some cases, but the bulk of my data is already compressed or not much compressible (think videos, images, compressed archives, game assets). So the trade off doesn’t make much sense to me.
Btrfs has many advantages over ext4, but being faster isn’t one of them.
Mint doesn’t default to btrfs, but will use it if you so choose during install. And it integrates fantastically with Timeshift. I’ve set up daily and weekly snapshots and have peace of mind.
XFS. It fills the same role as ext4 but it’s less likely to lose your data and that’s probably the most important part of a file system. Not that ext4 is bad or anything, but XFS is good. The only downside to XFS is you can’t shrink the filesystem size.
I like btrfs but only cause it got transparent compression. I don’t need the extra disk space and it only helps a bit but I just think it’s neat
If you’re on spinning rust with a modern CPU, compression actually helps your read/write speeds quite a bit. It’s faster for the CPU to compress/decompress then read/write less data because hard drives are so slow in comparison.
I’m going to go against the flow here and say BTRFS. It’s stable enough to the point of being a non consideration. You get full backups using a negligible amount of storage. Even using it on Windows is easier than using ext4 with the winbtrfs driver.
If you’re just doing a vanilla Linux install, ext4 is the way to go.
Upvoted. Not everyone wants to rely on backups and restore broken system every month like on BTRFS
And LVM is more than good enough for occasional snapshots before a major upgrade.
What’s lvm like compared to btrfs?
LVM creates “block devices” and is FS agnostic. You can install btrfs on an LVM volume if you wanted. Or any other FS for that matter.
But since it doesn’t know anything about the FS it can be a bit more cumbersome to modify volumes (especially when shrinking).
Well lvm makes a shit filesystem and btrfs is useless at volume management.
We’re not in 2014 anymore.
File system is a core component of any electronic system. Even if it’s just 1% less stable than other ones, it’s still less stable. Maybe it’s faster in some cases and supports better backups but ehh idk if it’s worth it. Losing documents is something you probably want to avoid at all costs
Yeah, but it isn’t noticeably “less stable” if at all anymore* unless you mean stable as in “essentially in maintenance mode”, and clearly good enough for SLES to make it the default. Stop spreading outdated FUD and make backups regularly if you care about your documents (ext4 won’t save you from disk failure either which is probably the more likely scenario).
* not talking about the RAID 5/6 modes, but those are explicitly marked unstable
My short BTRFS history
- Installed on a 1TB NVME
- used for 2 years
- Rebased my system a ton, used rpm-ostree a ton (which uses BTRFS for the snapshots I think?)
- Physically broke the SSD by bending (lol used a silicon cooler pad but it bent it) which resulted in hardware crashes
- With
ddbarely managed to get all the data onto a 1TB SATA SSD dd-ed the SATA SSD onto a 2TB NVME- deleted and restored the MBR, resized the BTRFS partition to max, resized the BTRFS filesystem to max, balanced it
Still works, never had a single failure
Well gtk if it’s really as stable as ext4. I will still stick to ext4 though because why change what already works well and tested on almost any machine you can possibly imagine?
I suppose by being more efficient, “using modern technology” (everything saving Google, Meta, Amazon etc. money and is thus extremely well funded, all server related stuff), is good for the environment.
If something runs faster on the same hardware, it may use less energy. It may also just be restricted in hardware usage, like not using multithreading.
Linux Distros shipping x86_64-v2 packages is a whole other problem…
I have an x86_64-v2 CPU so I highly disagree with your statements.
I disagree. My partition is ext4, but Timeshift saved my ass when an upgrade went wrong. I just had to restore the system from a previous snapshot before the upgrade.
Of course updates can break stuff. What I don’t understand is why would you intentionally go for a less stable FS that can break and corrupt all files? It’s especially bad on old machines with limited space where full backups are not possible
If full backups aren’t possible that’s an administrator failure.
Reliance on a file system to never fail rather than have proper backups, is an administrator failure.
ANY system can, and will, fail. Thinking and behaving otherwise is an administrator failure.
“Everything gets gone, sooner or later” - being prepared for it is good administrator behaviour.
Yes but why intentionally choose a worse option? Sorry but it’s not very smart imo.
And not having enough space is not an administrator failure. It’s usually budget issue. And are you saying that making apps bloated (like severely bloated) is ok and the user should always be blamed for having lower hardware?
I never tested BTRFS on SSDs under 128GB or even HDDs, but never had a corrupted one.
Those anecdotes are worth little so it would be best to have current data.
One of the above points was that the claims are outdated, which would be really interesting to verify.
Like, making a study with many different parameters
- hdd, sata ssd, nvme ssd, emmc, etc.
- size: 50-200MB, 1GB, 16GB, 128GB, 500GB, 4TB (from small embedded, to IOT, to usb flash drive, to smartphone, to laptop, to Server/Backup)
- amount of usage: percentage filled, read/write per minute
- BTRFS actions: snapshots, balance, defragment
Are you talking about ext4 or BTRFS?
Updates can break stuff on any file system but BTRFS is known for worse stability, at least in the past
I’m running it for over 3 years as complete linux moron with no issues whatsoever. It was default in openSUSE and its automatic snapshot feature saved my ass multiple times. I’ve heard everyone saying ext4 is super stable and I should use it, but I went with default and can’t complain.
Good that you mentioned that. Reminded me that I have an Arch Linux install here where I forgot that I did choose BTRFS during installation. Within maybe a month I noticed FS errors. Looked scary. Nervously searching for documentation was even more scary :
https://wiki.archlinux.org/title/btrfs#btrfs_check ->
This article or section is out of date.(Discuss in Talk:Btrfs) Warning: Since Btrfs is under heavy development, especially the btrfs check command, it is highly recommended to create a backup and consult btrfs-check(8) before executing btrfs check with the --repair switch.What is this? My beloved Arch Wiki is not 100% perfect!
Then found this :
WARNING: Using ‘–repair’ can further damage a filesystem instead of helping if it can’t fix your particular issue.
Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. E.g. some other software or hardware bugs can fatally damage a volume.
I figure this explains the popularity of BTRFS snapshot configurations. Luckily I had some backups :)
Filesystem snapshots won’t help, if the filesystem itself corrupts. But I’ve been using BTRFS for 6 years now and haven’t had a file system corruption, so mileage may obviously vary.
