As with every software/product: they have different features.
ZFS is not really hip. It’s pretty old. But also pretty solid. Unfortunately it’s licensed in a way that is maybe incompatible with the GPL, so no one wants to take the risk of trying to get it into Linux. So in the Linux world it is always a third-party-addon. In the BSD or Solaris world though …
btrfs has similar goals as ZFS (more to that soon) but has been developed right inside the kernel all along, so it typically works out of the box. It has a bit of a complicated history with it’s stability/reliability from which it still suffers (the history, not the stability). Many/most people run it with zero problems, some will still cite problems they had in the past, some apparently also still have problems.
bcachefs is also looming around the corner and might tackle problems differently, bringing us all the nice features with less bugs (optimism, yay). But it’s an even younger FS than btrfs, so only time will tell.
ext4 is an iteration on ext3 on ext2. So it’s pretty fucking stable and heavily battle tested.
Now why even care? ZFS, btrfs and bcachefs are filesystems following the COW philisophy (copy on write), meaning you might lose a bit performance but win on reliability. It also allows easily enabling snapshots, which all three bring you out of the box. So you can basically say “mark the current state of the filesystem with tag/label/whatever ‘x’” and every subsequent changes (since they are copies) will not touch the old snapshots, allowing you to easily roll back a whole partition. (Of course that takes up space, but only incrementally.)
They also bring native support for different RAID levels making additional layers like mdadm unnecessary. In case of ZFS and bcachefs, you also have native encryption, making LUKS obsolete.
For typical desktop use: ext4 is totally fine. Snapshots are extremely convenient if something breaks and you can basically revert the changes back in a single command. They don’t replace a backup strategy, so in the end you should have some data security measures in place anyway.
It likely has an edge. But I think on SSDs the advantage is negligible. Also games have the most performance critical stuff in-memory anyway so the only thing you could optimize is read performance when changing scenes.
But again … practically you can likely ignore the difference for desktop usage (also gaming). The workloads where it matters are typically on servers with high throughput where latencies accumulate quickly.
I remember reading somewhere that btrfs has good performance for gaming because of deduplication. I’m using btrfs, haven’t benchmarked it or anything, but it seems to work fine.
Having tried NTFS, ext4 and btrfs, the difference is not noticeable (though NTFS is buggy on Linux)
Btrfs I believe has compression built in so is good for large libraries but realistically ext4 is the easiest and simplest way to do so I just use that nowadays
Perhaps I’m guilty of good luck, but is the trade off of performance for reliability worth it? How often is reliability a problem?
As a different use case altogether, suppose I was setting up a NAS over a couple drives. Does choosing something with COW have anything to do with redundancy?
Maybe my question is, are there applications where zfs/btrfs is more or less appropriate than ext4 or even FAT?
are there applications where zfs/btrfs is more or less appropriate than ext4 or even FAT?
Neither of them likes to deal with very low amounts of free space, so don’t use it on places where that is often a scarcity. ZFS gets really slow when free space is almost none, and nowadays I don’t know about BTRFS but a few years ago filling the partition caused data corruption there.
For fileservers ZFS (and by extension btrfs) have a clear advantage. The main thing is, that you can relatively easily extend and section off storage pools. For ext4 you would need LVM to somewhat achieve something similar, but it’s still not as mighty as what ZFS (and btrfs) offer out of the box.
ZFS also has a lot of caching strategies specifically optimized for storage boxes. Means: it will eat your RAM, but become pretty fast. That’s not a trade-off you want on a desktop (or a multi purpose server), since you typically also need RAM for applications running. But on a NAS, that is completely fine. AFAIK TrueNAS defaults to ZFS. Synology uses btrfs by default. Proxmox runs on ZFS.
ZFS cache will mark itself as such, so if the kernel needs more RAM for applications it can just dump some of the ZFS cache and use whatever it needs.
I see lots of threads on homelab where new users are like “HELP MY ZFS IS USING 100% MEMORY” and we have to talk them off that ledge: unused RAM is wasted RAM, ZFS is making sure you’re running fast AF.
In theory. But how it is implemented in current systems, reserved memory can not be used by other processes and those other processes can not just ask the hog to give some space. Eventually, the hog gets OOM-killed or the system freezes.
ZFS is not really hip. It’s pretty old. But also pretty solid. Unfortunately it’s licensed in a way that is maybe incompatible with the GPL, so no one wants to take the risk of trying to get it into Linux. So in the Linux world it is always a third-party-addon. In the BSD or Solaris world though …
Also ZFS has tendency to have HIGH (really HIGH) hardware/CPU/memory requirements.
It was originally designed for massive storage servers (“zettabyte” file system) rather than personal laptops and desktops. It was before the current convergence trend too, so allocating all of the system resources to the file system was considered very beneficial if it could improve performance.
I haven’t meant it as the criticism of ZFS. It is just so, and perhaps there were good reasons for it. Now (especially with the convergence trend) it hurts.
In case of ZFS and bcachefs, you also have native encryption, making LUKS obsolete.
I don’t think that it makes LUKS obsolete. LUKS encrypts the entire partition, but ZFS (and BTRFS too as I know) only encrypt the data and some of the metadata, the rest is kept as it is.
Data that is not encrypted can be modified from the outside (the checksums have to be updated of course), which can mean from a virus on a dual booted OS to an intruder/thief/whatever.
If you have read recently about the logofail attack, the same could happen with modifying the technical data of a filesystem, but it may be bad enough if they just swap the names of 2 of your snapshots if they just want to cause trouble.
Btw COW isn’t necessarily (and isn’t at least for ZFS) a performance trade-off. Data isn’t really copied, new data is simply written elsewhere on the disk (and the old data is not marked as free space).
Ultimately it actually means “the data behaves as though it was copied,” which can be achieved in many ways. There are many ways to do that without actually copying.
So let me give an example, and you tell me if I understand. If you change 1MB in the middle of a 1GB file, the filesystem is smart enough to only allocate a new 1MB chunk and update its tables to say “the first 0.5GB lives in the same old place, then 1MB is over here at this new location, and the remaining 0.5GB is still at the old location”?
If that’s how it works, would this over time result in a single file being spread out in different physical blocks all over the place? I assume sequential reads of a file stored contiguously would usually have better performance than random reads of a file stored all over the place, right? Maybe not for modern SSDs…but also fragmentation could become a problem, because now you have a bunch of random 1MB chunks that are free.
I know ZFS encourages regular “scrubs” that I thought just checked for data integrity, but maybe it also takes the opportunity to defrag and re-serialize? I also don’t know if the other filesystems have a similar operation.
Not OP, but yes, that’s pretty much how it works. (ZFS scrubs do not defrgment data however).
Fragmentation isn’t really a problem for several reasons.
Some (most?) COW filesystems have mechanisms to mitigate fragmentation. ZFS, for instance, uses a special allocation strategy to minimize fragmentation and can reallocate data during certain operations like resilvering or rebalancing.
ZFS doesn’t even have a traditional defrag command. Because of its design and the way it handles file storage, a typical defrag process is not applicable or even necessary in the same way it is with other traditional filesystems
Btrfs too handles chunk allocation effeciently and generally doesn’t require defragmentation, and although it does have a defrag command, it’s almost never used by anyone, unless you have a special reason to (eg: maybe you have a program that is reading raw sectors of a file, and needs the data to be contiguous).
Fragmentation is only really an issue for spinning disks, however, that is no longer a concern for most spinning disk users because:
Most home users who still have spinning disks use it for archival/long term storage/media that rarely changes (eg: photos, movies, other infrequently accessed data), so fragmentation rarely occurs here and even if it does, it’s not a concern.
Power users typically have a DAS or NAS setup where spinning disks are in a RAID config with striping, so the spread of data across multiple sectors actually has an advantage for averaging out read times (so no file is completely stuck in the slow regions of a disk), but also, any performance loss is also generally negated because a single file can typically be read from two or more drives simultaneously, depending on the redundancy config.
Enterprise users also almost always use a RAID (or similar) setup, so the same as above applies. They also use filesystems like ZFS which employs heavy caching mechanisms, typically backed by SSDs/NVMes, so again, fragmentation isn’t really an issue.
Cool, good to know. I’d be interested to learn how they mitigate fragmentation, though. It’s not clear to me how COW could mitigate the copy cost without fragmentation, but I’m certain people smarter than me have been thinking about the problem for my whole life. I know spinning disks have their own set of limitations, but even SSDs perform better on sequential reads over random reads, so it seems like the preference would still be to not split a file up too much.
You should delete the contents of the cache folder instead of the folder itself as sadly some apps will break pretty spectacularly if they can’t find the folder itself. Otherwise you’re entirely correct
General trick for unknowns like this, you can rename a folder, open the applications. If they work, it is likely safe to delete that folder. If not, you rename that folder back. A simple way to test removing something non-destructively.
I’ve started using BTRFS on my laptop with OpenSUSE and on my Steam Deck. It does two things for me, which I’m interested in. On OpenSUSE it does a snapshot before every system update. So if anything goes wrong I can easily roll back.
On the Steam Deck I love the deduplication. It’s really great for a ton of Windows games that all need their own little “Windows” environment which amounts to a GB or two per game. With BTRFS I only use that space once.
Can you elaborate more on deduplication? Is this a feature you setup, or does it sort of work out of the box? This is a new concept to me, but sounds incredibly useful, especially in that scenario.
I used a script that did everything for me, so I’m not 100 % sure. But as far as I know you enable the feature at mount time and then every time you copy something only a reference is copied until you actually do a change to the new or old file.
For everything else a cronjob runs every week or so to search for unnecessary duplicates.
And if a copied file is changed, btrfs only stores the difference instead of two complete files. E.g. if the 1GB file1 is copied to file2, they will take 1GB total. If 100MB is appended to file2, the total storage usage is 1,1GB
KDE5 is great and does everything I need it to. I feel like upgrading is just going to introduce issues while bringing nothing new to the table.
The only thing I would like to change are bigger scrollbars or have the ability to easily resize them. Something tells me this isn’t going to be included in KDE6, though.
The horrible part is it was. Your other choice was ext2, which wasted so many lifetimes with its hours long fsck times. Reiserfs was a cut above the rest, we would all be using it today if it weren’t for that one teensy-weensy legal issue.
I have an old drive with it in there. The drive is going bad so I haven’t messed with it too much. I never knew at the time why the development and shine faded so quickly.
After using ext4 for yyyeeeaaaarrrrrsss, when I upgraded my MX21 to MX23 I used btrfs, with subvolumes, especially for easy backup/snapshot/timeshift.
Just at install, super easy, create a small ext4 boot partition on the SSD, then a big LUKS partition, format with btrfs, create subvolumes for / /home /var /swap and that’s it. No hassle with sizing correctly.
btrfs seems pretty stable. I see no diff in performance compared to ext4 because my application are not that dependant to FS speed, and with SSD anyway?
Yes, use what you know. Neither LXLE nor LXDE are end of life as claimed in other comments. The latest LXLE release is supported until 2030, which is five years longer than Windows 10.
I appreciate your response. it’s good to know I’m safe running what I know. And cerement gave me some good info so I can learn more about different distros. :)
A typical Linux distro, especially lightweight and simpler ones like Arch, will of course be better than a bloated OS, like Pop or Windows. The only problem with Linux distros might be the choice of tools - X and AMD will work much better overall than Wayland and Nvidia.
Just that many people may have an Nvidia GPU before deciding to use Linux, and some people just prefer to use Wayland over X for literally everything else.
My PC with Wayland + Nvidia has so many problems with gaming, especially flickering and performance, while my Laptop with Wayland + integrated Intel graphics has no problems at all - even in games, that I wonder if Nvidia + Wayland still really sucks ass or if my GPU is just broken. Currently there’s a bug where frames are ‘switched’ somehow, so it’s not Frame 1, Frame 2, … Frame n, but Frame 1, Frame 3, Frame 2, Frame 5, Frame 6, Frame 4 etc.
I expect it to be fixed by an update of nvidia in the future, but there are always such bugs.
If my experience is any indicator, your GPU is fine :(. Any chance you’re using mixed display scalings? I’ve got an RTX 3050 eGPU for my Plasma/Wayland laptop, and for the most part it actually works fairly smoothly (albeit more slowly compared to windows), but if I try to run a game at a higher resolution than my monitor (used by Plasma for mixed scaling) I get constant flashing/frame shifting, but when I drop it down to the native 1080p it starts working again
As a side note, X and eGPUs do not play well together, but Wayland is literally plug and play after installing the drivers–I can even hot plug/unplug as long as nothing’s using the GPU!
That frame issue is because of the fact that Nvidia uses “explicit sync” and AMD/Intel use “implicit sync” - XWayland is built to only support implicit syncing for now (Nvidia is trying to get it changed), and since most games right now run under XWayland… Along with a ton of apps of course.
Until then, that issue won’t be resolved sadly. It’s what finally pushed me to get an AMD card since the issue has been open for over a year with a ton of back and forth.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.