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.
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.
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.
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.
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.
Most people should use ext4. Only use something else if you want to tinker and don't need long term data storage.
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. Nothing can be guaranteed for such drives.
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.
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.
Btrfs or xfs. Sometimes ext4.
ITT 5 answers by 4 people
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.
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.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
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 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
At the end of the day though after all of our storage tests conducted on Clear Linux, EXT4 came out to being just 2% faster than F2FS for this particular Intel Xeon Gold 5218 server paired with a Micron 9300 4TB NVMe solid-state drive source
I'll suggest XFS.
I use ext4 for my desktop and zfs for my media server. Ext4 is faster, ZFS is more accurate and less corruptable.
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:
undefined
filesystem - must be only single device
filesystem - must have only single data profile
subvolume - cannot be snapshotted if it contains any active swapfiles
swapfile - must be preallocated (i.e. no holes)
swapfile - must be NODATACOW (i.e. also NODATASUM, no compression)
With active swapfiles, the following whole-filesystem operations will skip swapfile extents or may fail:
undefined
balance - block groups with extents of any active swapfiles are skipped and reported, the rest will be processed normally
resize grow - unaffected
resize shrink - works as long as the extents of any active swapfiles are outside of the shrunk range
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
device delete - if the device has been added as above, it can be also deleted
device replace - ditto
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.
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.
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?
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.
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
ext4 maxes out at a few tb
Max filesystem size is 1 EiB = 1048576 TiB.
More than enough!
eh which ever value it is smaller then btfrs or zfs
FAT32
Great for USBs