What filesystem is currently best for a single nvme drive with regard to performance read/write as well as stability/no file loss? ext4 seems very old, btrfs is used by RHEL, ZFS seems to be quite good… what do people tend to use nowadays? What is an arch users go-to filesystem?
Ext4 being “old” shouldn’t put you off. It is demonstratively robust with a clear history of structure integrity. It has immense popularity and a good set of recovery tools and documentation. These are exactly what you are looking for in a filesystem.
I’m not saying EXT4 is the best for your requirements, just that age of a file system is like fine wine.
Calling Ext4 “old” is like saying that MySQL isn’t webscale
Here is an alternative Piped link(s): https://piped.video/b2F-DItXtZs
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source, check me out at GitHub.
ext4 being old, and still being the main file system most distros use by default, should be enough alone to tell you being old isnt bad.
it means its battle tested, robust, stable, and safe. Otherwise it wouldnt be old and still be in widespread use.
This is exactly my outlook. Ext4 has proven itself as a robust and reliable file system.
RHEL uses XFS as default.
Currently running BTRFS. Next fs is gonna be ext4. No need for anything else
Are you saying you don’t like btrfs?
It makes recovery harder, and it’s just not something I need
i would generally recommend XFS over ext4 for anything where a CoW filesystem isn’t needed. in my experience, it performs better than ext4 at most workloads, and still supports some nifty features like reflink copies if you want them.
btrfs is great for system stability because of snapshots. You can set it up to automatically make snapshots at a timed interval or every time you run pacman.
If something breaks, you can just revert to a previous snapshot. You can even do this from grub. It’s a bit hard to set up, so if you want, you could use an arch based distro which automatically sets it up like GarudaOS.
Too bad btrfs still doesn’t support encryption natively, unlike ext4.
How much is ext4 filesystem-level encryption actually used though?
I guess not much on desktop Linux, but every Android phone uses it. Really wish every Linux desktop would start encrypting their /home partition by default, which is the standard by many other operating systems.
I’m pretty sure default Android runs almost always on F2FS.
Got any source for that? Android has traditionally always used ext4 afaik, not sure if that changed in the last few years.
Wiki says:
Motorola Mobility has used F2FS in their Moto G/E/X and Droid phones since 2012. Google first used F2FS in their Nexus 9 in 2014. However Google’s other products didn’t adopt F2FS until the Pixel 3 when F2FS was updated with inline crypto hardware support.
Huawei has used F2FS since the Huawei P9 in 2016. OnePlus has used F2FS in the OnePlus 3T. ZTE has used F2FS since the ZTE Axon 10 Pro in 2019.
I assume since Google is involved that more and more Android phones will adopt F2FS in the future.
So only a handful of devices support F2FS right now and is not the default
Android on many OEMs migrated to EROFS from F2FS for system partition.
Or OpenSUSE , all setup out of the box for btrfs, snapshots, grub rollback, and cleanup timers, etc.
Wow, first time I’ve seen GarudaOS recommended by someone who’s not me. Awesome distro, daily driver on my gaming rig.
There are dozens of us. Dozens!
I use it for home and work! I quite like it though I miss latte dock still, dragging windows from the top bar was just so useful for me
ext4 works perfectly fine for me and most people.
If you’re married stay away from ReiserFS.
Ah, ReiserFS. I remember when it was the cool kid’s choice. Then with the murdering it went out of style. They were weird times.
why is the a column called “murders your wife”
Wikipedia vandalism from ages ago.
It’s an old version of the article.
It has been suggested by some that there is no relationship between Reiser murdering wives and ReiserFS murdering file systems, but most steer clear of both out of an abundance of caution.
Even now? I remember when it was new I tried it, must have been 20 or so years ago. Super fast for the time, but had a nack for randomly corrupting data. After the third reformat, I went back to ext2.
Hans Reiser murdered his wife.
Oh. I did not know that! I thought it was some vague reference to losing entire weekends fixing the corrupt data.
deleted by creator
GPL or GTFO gang
Thank you
Been using BTRFS for all disks and purposes for a few years, I would recommend it with the requirement that you research it first. There are things you should know, like how/when to disable CoW, how to manage snapshots, how to measure filesystem use, and what the risks/purposes of the various btrfs operations are. If you know enough to avoid doing something bad with it, it’s very unlikely to break on you.
Huh. I just realized the problem with “don’t use upvotes to show agreement.” It means encouraging low-effort “me-too” posts.
I don’t have much to add to your comment, just… me too.
Me too!
Ext4 is all I use, except for boot partitions that require different filesystems.
Most people should use ext4. Only use something else if you want to tinker and don’t need long term data storage.
Be conservative and use the simplest thing that supports your needs and don’t be suckered by feature lists. I have never needed more than ext4. It generally has the best all round performance and maturity is never a bad thing when it comes to filesystems. It isn’t most suitable for some embedded and enterprise environments and if you are working with those you generally know the various tradeoffs.
I run ext4 inside lvm (inside luks)
Ext4 is old, but fast and very robust. You won’t loose data or corrupt the filesystem if your system looses power. It can even survive partial wipes, if you accidentally overwrite the first few megs of you drive with a messed up dd, nearly all your data will be recoverable, including filenames and directory structure.
It doesn’t have very fancy features, but it is the best tested and most robust option available. (also the fastest due to its simplicity)
Btrfs has things like copy on write files that can protect you from an accidental rm, but this won’t save you from drive failures, so you still need backups for important data.
You won’t loose data or corrupt the filesystem if your system looses power.
Some secondary storage devices ignore standards and outright lie about sectors being successfully written when they are actually scheduled to be written out of order. This causes obvious problems when power failure prevents the true writes from completing.
Btrfs or xfs. Sometimes ext4.
ITT 5 answers by 4 people
If you are planning to have any kind of database with regular random writes, stay away from btrfs. It’s roughly 4-5x slower than zfs and will slowly fragment itself to death.
I’m migrating a server from btrfs to zfs right now for this very reason. I have multiple large MySQL and SQLite tables on it and they have accumulated >100k file fragments each and have become abysmally slow. There are lots of benchmarks out there that show that zfs does not have this issue and even when both filesystems are clean, database performance is significantly higher on zfs.
If you don’t want a COW filesystem, then XFS on LVM raid for databases or ext4 on LVM for everything else is probably fine.
Did you disable CoW for your database with btrfs? E.g. for PostgreSQL, the Arch Wiki states:
If the database resides on a Btrfs file system, you should consider disabling Copy-on-Write for the directory before creating any database.
From arch wiki:
Disabling CoW in Btrfs also disables checksums. Btrfs will not be able to detect corrupted nodatacow files. When combined with RAID 1, power outages or other sources of corruption can cause the data to become out of sync.
No thanks
that’s no different than any “normal” filesystem with a traditional block-level RAID solution
Not really. You can still use dm-verity for a normal raid and get checksumming and normal performance, which is better and faster than using btrfs.
But in any case, I’d recommend just going with zfs because it has all the features and is plenty fast.
ZFS lacks some features that btrfs has, such as creating CoW clones of individual files (rather than having to snapshot a whole subvolume).
personally i’ve been using btrfs on pretty much everything for about two years, ranging from multiple >100TB filesystems spanning 8 spinning rust drives to individual flash drives and had very few issues (compared to my experiences with ext4 on mdadm). snapshots/reflink copies have made many of my workflows much easier, adding/removing/replacing devices pretty much Just Work™, and the fact that everything is checksummed gives me a piece of mind i didn’t know i needed. sure, ZFS has pretty much the same featureset, but it’s not in the mainline kernel and seems to lack some of btrfs’ flexibility (from the research i’ve done in the past, like adding/removing disks to an existing pool is still experimental).
what i’m really excited for is bcachefs, which takes what i consider the best features of both btrfs and ZFS and then steps them up a notch (e.g. ability to configure RAID settings and prefer specific drives on a per-file/per-directory level). as soon as it’s stable enough to be mainlined i’ll definitely be migrating most of my btrfs filesystems to that.
If you don’t want a COW filesystem, then XFS on LVM
XFS supports reflinks, so it’s kind of snapshot and CoW capable. Someone was working on some tool to make snapshots on XFS by utilizing reflinks.
