this post was submitted on 07 Dec 2023

204 points (96.8% liked)

Linux

48130 readers

431 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
No misinformation
No NSFW content
No hate speech, bigotry, etc

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago

MODERATORS

nooter692@lemmy.ml

AgreeableLandscape@lemmy.ml

MarcellusDrum@lemmy.ml

cypherpunks@lemmy.ml

cyclohexane@lemmy.ml

d3Xt3r@lemmy.nz

204

What's with all these hip filesystems and how are they different? (lm.paradisus.day)

submitted 11 months ago* (last edited 11 months ago) by rutrum@lm.paradisus.day to c/linux@lemmy.ml

83 comments fedilink hide all child comments

You know, ZFS, ButterFS (btrfs...its actually "better" right?), and I'm sure more.

I think I have ext4 on my home computer I installed ubuntu on 5 years ago. How does the choice of file system play a role? Is that old hat now? Surely something like ext4 has its place.

I see a lot of talk around filesystems but Ive never found a great resource that distiguishes them at a level that assumes I dont know much. Can anyone give some insight on how file systems work and why these new filesystems, that appear to be highlights and selling points in most distros, are better than older ones?

Edit: and since we are talking about filesystems, it might be nice to describe or mention how concepts like RAID or LUKS are related.

top 50 comments

sorted by: hot top controversial new old

[–] aksdb@feddit.de 124 points 11 months ago* (last edited 11 months ago) (3 children)

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.

*Edit: forgot a word.

[–] excitingburp@lemmy.world 37 points 11 months ago (1 children)

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.

[–] teawrecks@sopuli.xyz 5 points 11 months ago (1 children)

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.

[–] d3Xt3r@lemmy.nz 6 points 11 months ago* (last edited 11 months ago) (1 children)

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.

[–] teawrecks@sopuli.xyz 3 points 11 months ago

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.

[–] Fizz@lemmy.nz 5 points 11 months ago (6 children)

So ext4 is the best for desktop gaming performance?

[–] aksdb@feddit.de 25 points 11 months ago

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.

Here are some comparisons: https://www.phoronix.com/news/Linux-5.14-File-Systems

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.

[–] flashgnash@lemm.ee 10 points 11 months ago (2 children)

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

[–] Cwilliams@beehaw.org 7 points 11 months ago (1 children)

Well that's because any support for it is unofficial. NTFS is made for Windows

[–] MonkderZweite@feddit.ch 7 points 11 months ago (1 children)

And proprietary and an old piece of garbage.

[–] Cwilliams@beehaw.org 6 points 11 months ago

I didn't want to sound to harsh, but yea

load more comments (1 replies)

[–] skullgiver@popplesburger.hilciferous.nl 9 points 11 months ago* (last edited 11 months ago)

[This comment has been deleted by an automated system]

[–] aberrate_junior_beatnik@lemmy.world 8 points 11 months ago (1 children)

I'd be surprised to find out there was one filesystem that consistently did better than others in gaming performance. ext4 is a fine choice, though.

load more comments (1 replies)

load more comments (2 replies)

[–] rutrum@lm.paradisus.day 4 points 11 months ago (1 children)

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?

[–] aksdb@feddit.de 14 points 11 months ago (1 children)

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.

[–] 4am@lemm.ee 11 points 11 months ago (2 children)

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.

[–] aksdb@feddit.de 6 points 11 months ago

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.

In theory. Practically unless I limit the max ARC size, processes get OOM killed quite frequently here.

load more comments (1 replies)

[–] possiblylinux127@lemmy.zip 45 points 11 months ago (1 children)

ZFS is a crazy beast that's best for high end server systems with tiered storage and lots of RAM.

ext4 is really just a basic file system. Its superior to NTFS and fat as it does have extra features to try to prevent corruption but it doesn't have a large feature set.

Btrfs is kind of the new kid on the block. It has strong protection against corruption and has better real world performance than ext4. It also has more advanced features like sub volumes and snapshots. subvolumes are basically virtual drives.

Another few older options include things like XFS but I won't go into those.

List of filesystems: https://en.m.wikipedia.org/wiki/Comparison_of_file_systems

[–] Lojcs@lemm.ee 13 points 11 months ago (9 children)

and has better real world performance than ext4

Source? Most benchmarks I've seen it lags behind

[–] possiblylinux127@lemmy.zip 5 points 11 months ago (1 children)

My personal testing

load more comments (8 replies)

[–] bjoern_tantau@swg-empire.de 24 points 11 months ago* (last edited 11 months ago) (1 children)

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.

[–] rutrum@lm.paradisus.day 11 points 11 months ago (3 children)

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.

[–] bjoern_tantau@swg-empire.de 13 points 11 months ago (1 children)

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.

[–] Chewy7324@discuss.tchncs.de 15 points 11 months ago (1 children)

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

[–] Discover5164@lemm.ee 7 points 11 months ago

it's not automatic since it will eat resources while it's running. but it's a feature of btrfs.

load more comments (1 replies)

[–] AMDIsOurLord@lemmy.ml 22 points 11 months ago (4 children)

Using Btrfs you can do some pretty cool snapshotting: It's basically like system restore of Windows but MUCH faster and pretty seamless. Even if you annihilate the whole operating system you can restore the snapshot and voila, have fun! It also has compression which can save some wear on SSDs and of course give you some more free(tm) storage space, which is cool [actual benefits depend on workload*]

load more comments (4 replies)

[–] jokro@feddit.de 17 points 11 months ago* (last edited 11 months ago) (4 children)

btrfs = B-tree filesystem

B-trees are a data structure.

load more comments (4 replies)

[–] callyral@pawb.social 15 points 11 months ago (4 children)

related question, although i don't think it's big enough for a post of its own.

if i use btrfs subvolumes, does it mean that i can have one EFI partition and one root partition, and then subdivide the root partition using subvolumes? how would that work during the installation process? or is it done after installation?

[–] mhz@lemm.ee 6 points 11 months ago* (last edited 11 months ago) (1 children)

One EFI + one ROOT partition is what I do on both my laptop and desktop for years, /home is a subvolume to my root partition. This setup suits my needs as I don't have to worry about how big should my root or home (gaming) partition should be.

I use Arch on my desktop and Opensuse on my laptop. They both have options to set up subvolumes from their installer, Debian does not, and I'm not sure about other distros, but you can always set that up after installation, just make your home partition the last one (after the root partition) so you can easily delete it after and grow the root partition without much blocks relocation.

[–] danielquinn@lemmy.ca 4 points 11 months ago* (last edited 11 months ago) (1 children)

I've never heard of sub volumes. What do they do for me? Why not just partition the disk or store everything on the one partition?

[–] mhz@lemm.ee 5 points 11 months ago

I like to think a subvolume is a directory on my filesystem that:

Acts as an independent filesystem.
Shares it's parent size (unless quotas are set in place)
Can be mounted/unmounted any time
Excluded from their parent partition's snapshots. (a /home subvolume is exluded from / snapshots).
Can be snapshot-ed independently.

This is by no mead a definition for BTRFS subvolume, but I hope you get the idea.

[–] lupec@lemm.ee 4 points 11 months ago

Pretty much, yeah. At some point I remember the recommendation being having a separate /boot as well due to incompatibilities with GRUB's save default option iirc, not sure that's a thing anymore.

Anyway, you usually set that up during the install process, although I'm not sure graphical installers let you handcraft btrfs subvolume mount points or even select them as such these days. Last I checked at least they either just used a default layout (@ and @home with Ubuntu, for instance) or treated it as a single volume with no further options.

load more comments (1 replies)

[–] lolcatnip@reddthat.com 15 points 11 months ago

ButterFS (btrfs...its actually "better" right?),

I'm still waiting to find out who the BCA Chefs are.

[–] BeefPiano@lemmy.world 11 points 11 months ago (2 children)

I don’t know about the new ones, but ReiserFS was a killer back in the day.

[–] n2burns@lemmy.ca 8 points 11 months ago

Bad joke.

[–] rotopenguin@infosec.pub 4 points 11 months ago (1 children)

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.

load more comments (1 replies)

[–] i_am_not_a_robot@feddit.uk 11 points 11 months ago (4 children)

I use f2fs on my Raspberry Pis, it's designed for flash storage and appears to have much better performance than ext4 on the same device. I'm not sure whether it's suitable for SSDs, or just SD cards and USB (these devices are optimised for FAT and f2fs utilises that optimisation). When I tried to use f2fs on a proper laptop it was too early and the distro didn't support booting from it. I assume that has changed now.

As for the others, I usually stick with ext4 as I've never seen a compelling reason not to.

load more comments (4 replies)

[–] Cwilliams@beehaw.org 9 points 11 months ago (1 children)

Not sure about the other ones, but I use Btrfs because of subvolumes and backups.

Subvolumes are like special folders inside of your partition that mount separately. Ex. In my btrfs partition, I have a @home partition that is mounted to /home

This makes it easier to choose what you are backing up, because you can say, "just copy everything in @home to the backup location"

If I got any of that wrong, feel free to correct me!

[–] zephr_c@lemm.ee 6 points 11 months ago (6 children)

I mean, is it actually easier to copy everything in @home than it is to copy everything in /home? Btrfs has always kinda felt like it's a bunch of extra steps to solve problems I don't have.

load more comments (6 replies)

[–] Frederic@beehaw.org 8 points 11 months ago* (last edited 11 months ago) (4 children)

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?

oh yeah, built-in compression too!

load more comments (4 replies)

[–] sexy_peach@feddit.de 4 points 11 months ago* (last edited 11 months ago)

you're forgetting about the all new bcachefs

dunno I also wonder if it's worth it for personal use

[–] chitak166@lemmy.world 3 points 11 months ago

I just use ext4.

load more comments