What Filesystem?
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?
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:
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
It's still quite a lot. Samsung is the inventor of F2FS and has a market share of 33%.
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.
https://en.wikipedia.org/w/index.php?title=Comparison_of_file_systems&oldid=209063556#Features
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.
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.
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. Nothing can be guaranteed for such drives.
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:
From arch wiki:
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.
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.
Btrfs or xfs. Sometimes ext4.
XFS is a possibility
That's what I use.
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).
Thank you
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.
I'm using btrfs for my desktop and laptop (and its snapshots have saved me a couple of times), and ZFS for my NAS and router. Both seem pretty robust.
ext4 is good enough.
ext4 is perfectly fine for my needs. It's stable and just works.
I use ext4 for my desktop and zfs for my media server. Ext4 is faster, ZFS is more accurate and less corruptable.
I usually just use EXT4, but perhaps you should check out F2FS. It's designed for solid state storage mediums, as while most were created with traditional spinning hard discs in mind
I'll suggest XFS.
It really depends on your priorities. Single drive is good for a home system with nothing really important on it.. once you get to wanting to keep it and where recovery from backups is too much downtime, you want at least a drive mirror.. nothing wrong with exr4+mdraid for that, although you don't get the checksumming that zfs gives it will be pretty fast & if a drive fails you can run degraded on one drive until you get the new drive in.
I've been running zfs for 10 years and not lost a single byte of data even after doing stupid shit like tripping over the sata cables and disconnecting half the drives. It's survived multiple drive failures (as long as the failures are on different bits of the disk, it recover get a clean copy onto a third drive, but it's a brown trousers moment when stuff like that happens).
Downsides, it aint fast, and it does tend to like lots of memory. You want it on your fileserver, not your gaming system.
IMO there's no point in a single drive zfs.. it'll warn you faster that the drive is f*cked but what do you do then?
I agree. Love ZFS for the NAS, but for a single drive desktop system, it is almost pointless and in my experience slower for desktop usage. ZFS is great for what it was designed for.
I still swear by F2FS, been super reliable and very good perf
Unfortunately it's not future proof. Max filesystem size is only 16 TB.
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!
You can make a swap file on btrfs.
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:
With active swapfiles, the following whole-filesystem operations will skip swapfile extents or may fail:
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.
O use ext4 at home and in servers that are not SLES HANA DB ones.
On SLES HANA servers I use ext4 for everything but the database partitions, for which SAP and SUSE support and recommend XFS.
In a few occasions people left the non-db partitions as the default on SUSE install, btrfs, with default settings. That turned out to cause unnecessary disk and processor usage.
I would be ashamed of justifying btrfs on a server for the possibility of undoing "broken things". Maybe in a distro hopping, system tinkering, unstable release home computer, but not in a server. You don't play around in a server to "break things" that often. Linux (differently from Windows) servers don't break themselves at the software level. For hardware breakages, there's RAID, backups, and HA reduntant systems, because if it's a hardware issue btrfs isn't going to save you - even if you get back that corrupted file, you won't keep running in that hardware, nor trust that "this" was the only and last file it corrupted.
EDIT: somewhat offtopic: I never use LVM. Call me paranoid and old fashioned, but I really prefer knowing where my data is, whole.
Facebook was using btrfs for some usecases. Not sure what you mean by breaking things?
Most comments suggesting btrfs were justifying it for the possibility of rolling back to a previous state of files when something breaks (not a btrfs breakage, but mishaps on the system requiring an "undo").
Ah, I see. While that use may be a good plan for home server, doing that for production server seems like a bandaid solution to having a test server and controlling deployed changes very carefully.
Exactly. A waste of server resources, as a productions server is not tinkerable, and shouldn't "break".
Ext4 for general pupose linux. Zfs for bsd network drives
I like btrfs cause of transparent compression but I'm pretty sure other filesystems like ZFS have that too
ext4.
Never used arch; just slackware and then enterprise linux.
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.
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.
For what? Client on a laptop or PC? Why not f2fs? On a server just trust good ol ext4 with some flash drive settings.
it would be for a PC and normal work/home use
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.
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.
So you're going to make snapshots of the ext4 filesystem onto the BTRFS one?
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?
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).
Noted. Thanks for your clear response. I'll just keep it simple have the OS snapshots on the same partition.
It's more important to backup your /home than /. /home is where you store your crucial files.
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
FAT32
Great for USBs
oh I just read up on this last knight. Yes ext4 is old but it is used because it is still works quite well. btrfs, dis anyone say that as butfarts, can handle much larger partitions ext4 maxes out at a few tb while btfrs can get much larger. ZFS can handle a around a billion tb but it needs a lot more resources to to even start
Max filesystem size is 1 EiB = 1048576 TiB.
More than enough!
eh which ever value it is smaller then btfrs or zfs