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?
If you really care about high performance on an SSD, use f2fs. This filesystem was made for SSDs specifically. Though ext4 and xfs are also really solid and shouldn’t be that much slower. But if you do care about squeezing out every bit out of performance, f2fs is definitely worth trying.
It’s a bit more experimental, yet I’ve been daily driving it for maybe a year or so at this point and it never caused trouble once, even with cutting edge mount options.
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.
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.
For both my home server and desktop I use XFS for root and ZFS (in some variety of raid or mirror) for /home and data storage. Any time I’ve tried btrfs for root (such as default fedora), inevitably it poops the bed. At this point, I stay far away from btrfs.
Ext4 is probably going to be the fastest. When it comes to reliability, old is good. If you don’t need any of the features Btrfs and ZFS, you’ll reap higher performance using Ext4. Otherwise ZFS is more feature-complete compared to Btrfs, however it’s generally not available as root fs option in OS installers. Ubuntu used to have it as an experimental option but I think that’s gone now. If you know what you’re doing you can use it as a root fs. Personally I’m using Ext4 on LVMRAID on a 2-way NVMe mirror. I might be switching to ZFS on root when I get to rebuild this machine. All my storage is using ZFS.
My current setup is fedora for the last 6 months. I started a live session, installed f2fs and then run the installer with a combination of f2fs + encryption. And it runs flawlessly and faster than any setup before.
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.
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.
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.
We’re moving towards more btrfs - or at least LVM+<other FS> where there’s no btrfs support - on as much of our server fleet as we can, since the lack of snapshotting on the other filesystems is making consistent backups way too expensive resource- and time-wise.
With LVM it’s at least possible to take a block-level snapshot - which is really inefficient compared to a file-level snapshot, but it at least provides a stable point for backups to run from, without having to pause all writes during the backup or risk running out a sliding window if allowing writes to continue.
For a home user (especially one who’s not as well versed in Linux or don’t have tinkering time), I’d personally suggest either ext4 - since it’s been the default for a while and therefore often what’s assumed in guides, or btrfs where distros include it as a default option - since they should be configured with snapshots out of the box in that case, which make it much harder for the system to break due to things like unexpected shutdowns while running updates.
I’d personally stay away from ZFS for any important data storage on home computers, since it’s officially not supported, and basically guaranteed never to be either due to licensing. It can remain a reasonable option if you have the know-how - or at least the tinkering time to gain said know-how, but it’s probably going to be suboptimal for desktop usage regardless.
I find btrfs pretty good for desktop use mostly due to convenience it offers with managing devices(adding new device or migrating data is trivial and does not need any downtime) and subvolumes(different mount options or excluding some data from snapshots).
It depends, for a normal user? Ext4, maybe btrfs because in terms of stability is the best {but u lose some functions like the ability to make a swap file, wich today isn’t really that useful, but u lose the ability to make one). Want something really fast fort large files? ZFS, but if u experience an energy loss it could be really catastrophic.
Ext in general is so good that even to this day android it’s still using EXT2, 2!
First of all, thanks this r news for me. But I don’t think is a good idea to use the swap file in btrfs.
It is supported since kernel 5.0
There are some limitations of the implementation in BTRFS and Linux swap subsystem:
<pre style="background-color:#ffffff;">
<span style="color:#323232;">filesystem - must be only single device
</span><span style="color:#323232;">
</span><span style="color:#323232;">filesystem - must have only single data profile
</span><span style="color:#323232;">
</span><span style="color:#323232;">subvolume - cannot be snapshotted if it contains any active swapfiles
</span><span style="color:#323232;">
</span><span style="color:#323232;">swapfile - must be preallocated (i.e. no holes)
</span><span style="color:#323232;">
</span><span style="color:#323232;">swapfile - must be NODATACOW (i.e. also NODATASUM, no compression)
</span>
With active swapfiles, the following whole-filesystem operations will skip swapfile extents or may fail:
<pre style="background-color:#ffffff;">
<span style="color:#323232;">balance - block groups with extents of any active swapfiles are skipped and reported, the rest will be processed normally
</span><span style="color:#323232;">
</span><span style="color:#323232;">resize grow - unaffected
</span><span style="color:#323232;">
</span><span style="color:#323232;">resize shrink - works as long as the extents of any active swapfiles are outside of the shrunk range
</span><span style="color:#323232;">
</span><span style="color:#323232;">device add - if the new devices do not interfere with any already active swapfiles this operation will work, though no new swapfile can be activated afterwards
</span><span style="color:#323232;">
</span><span style="color:#323232;">device delete - if the device has been added as above, it can be also deleted
</span><span style="color:#323232;">
</span><span style="color:#323232;">device replace - ditto
</span>
Yes, there are some limitations to be aware of, with how it interacts with certain features. But EXT4 doesn’t have any of those features at all. It doesn’t have CoW, or balance, or multi-device, or snapshots.
If the filesystem, is single-device, and you have the swapfile on it’s own nocow subvolume, preallocate the swapfile, and don’t try to take snapshots of it, it should be fine.
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.
Hi all. Apologies to hijack this thread. Figured it should be OK since it’s also on the topic of file systems.
Long story short, I need to reinstall Nobara OS and I plan to install Nobara on my smaller SSD drive with btrfs and set my /home folder to my larger nvme. I’m thinking of using ext4 for my /home and have snapshots of the main system stored on the nvme. Looking for a sanity check to see if this is OK or if I should be doing things differently. Thanks.
On the contrary, my intention is to make snapshots of the OS (btrfs) and my idea is to store the snapshots on the /home nvme drive (ext4).
I don’t know if that’s the standard practice or if I’m over complicating things. My SSD is only 240Gb (I think) while my nvme is a 1Tb drive, thus the intention to store snapshots on the nvme. Maybe the 240Gb is sufficient for say a month’s worth of snapshots plus the OS?
Yes, that’s true. Then again, I’m mainly using my PC for gaming and most of what will be in /home will be game installs. I have my photos and music backups in a separate HDD.
I think at the end of the day, what I’m trying to achieve with the btrfs snapshots is to be able to roll back my OS in case a system update goes wrong, or I did something I shouldn’t have. :p
No, that’s a very bad idea. BTRFS has deduplication, without that the snapshots would take up way to much space. Also it’s too many writes since ext4 doesn’t use cow and would have to do distinct writes for every snapshot.
The 240 gb are plenty for a root system without /home and years worth of snapshots on a btrfs volume, only the changes take up space so the amount of snapshots hardly matters.
For /home either ext4, xfs or btrfs is fine. Personally I only use a single btrfs volume and put certain folders in their own subvolumes so they can have different settings for snapshots(no snapshots for /home, tmp and cache folders).
Add comment