NTFS: what the fuck is this still doing in the wild. Malware maybe?
FAT: legacy FS for the lowest common denominator. Not good in any objective sense, but sometimes you are forced to use it.
ReiserFS: No one knows what ReiserFS actually does all we know is that the developer killed his wife and went to prison
Ext4: Old, stable, solid, and fast (even faster if you turn off journaling at the expense of reliability), but it’s missing some really nice modern features, like Copy-on-Write, snapshotting, and transparent compression
XFS: Ext4 for hipsters. Old, stable, fast, etc. There’s a recent push to try to make this a cool FS again with e.g. Stratis and reflinking support, but I don’t think it’s going to be the future. Still a great FS, but if you want XFS you’ll already know.
F2FS: Designed for optimal performance on flash storage, but generally it’s not good enough at that job to warrant using it over something else that has more features or is more reliable. Supports transparent compression, but oddly enough it doesn’t actually give you any extra free space when you compress. The compression is done only to reduce wear and tear on the cells.
ZFS: Gold standard FS, but incompatible licensing means it can’t be in the Linux kernel by default. It’s very stable, very fast, and likes to eat your RAM if you don’t tell it not to. Transparent ZSTD compression can be enabled to compress and decompress your files as you write/read, saving a lot of space. Its Copy-on-Write nature is more stable than traditional in-place editing because it won’t be vulnerable to power loss. As of OpenZFS 2.2 it also includes the reflinking feature, which will make file copies be instant within the same filesystem, reducing wear and tear. Notably if you’re making home-use RAID5/6 arrays it can feel very inflexible because it won’t let you add HDDs to your array on the fly (this was fixed on November 10th, 2023, but will not be released until OpenZFS 2.3 comes out). You’ll need to put some extra money into your home NAS setup to begin to see this filesystem shine, e.g. sacrificing half your disks for fast mirrored vdevs, which also allow reasonable growth. Buying a ton of RAM and maybe even an L2ARC SSD cache will also prevent wear and tear on your HDDs because most of your file reads will come from caches instead of the slow disks. This FS is designed for large data centers, and it’s really good at that.
BTRFS: ZFS for the rest of us. Contains a similar featureset to ZFS (Copy-on-Write, snapshots, transparent compression), but it’s better integrated into the Linux ecosystem. It’s generally worse in every other respect to ZFS, and it’s not as stable or time-tested either. It famously contains a “write-hole” bug that means RAID5/6 have the potential to eat your data, and so those are not recommended to be used. If you’re only considering a filesystem for a single drive (i.e. not a RAID), most of BTRFS’s downsides don’t matter. Many Linux distros are shipping with this FS as the default for the OS drive now, and it’s more or less being championed as “the future”.
BcacheFS: “The future v2”. Not even stable yet, that’s how you know it’s good. Contains unlimited features and zero bugs, 100% reliability, etc. All the best software is theoretical. We’ll see what happens when it’s fully mainlined into the Linux kernel.
MergerFS: fuck it what if filesystems weren’t even real. Transparently combine any other filesystems into a single logical filesystem. Usually used together with SnapRAID to make a more flexible home NAS RAID5/6 that can add or remove disks on the fly - this isn’t possible under ZFS and BTRFS shouldn’t be using RAID5/6 at all. Notably this configuration does not stripe data across disks, so even with an unmitigated disk failure you won’t lose the whole array. Disk performance won’t be as good as ZFS but flexibility and storage efficiency are probably a lot more important to a casual NAS owner.
So basically TLDR: BTRFS for home/OS use, MergerFS+SnapRAID backed by BTRFS disks for a budget home NAS, ZFS for a more expensive home NAS/server, and ZFS for enterprise.
I have not tried to use ZFS for home/OS but I’m guessing it’s not a good idea - most of ZFS’s advantages over BTRFS are regarding RAIDs, and poor Linux integration may cause headaches. Ext4/XFS is good for home/OS use if you have a real usecase, but otherwise BTRFS is generally just a better drop-in for most people these days. On HDDs you’re probably going to want to use ZFS or BTRFS because the transparent compression and copy-on-write nature will make the transfer speed not matter as much. On super-fast SSDs (e.g. for home/OS or a games drive), BTRFS might end up being slightly slower than Ext4/XFS, but transparent compression and copy-on-write will also prevent a ton of wear and tear on the physical SSD, so it really depends on your usecase.
If BTRFS is messing disks up in the wild today, I haven’t heard about it. You’ll find a few people saying that BTRFS messed up their disk in the past and they won’t touch it anymore, but Facebook runs all their stuff off BTRFS, and OpenSUSE+Fedora are shipping BTRFS by default to their users as well. We’d be hearing about it if there are real problems. Unfortunately, it’s easier to just say “BTRFS isn’t 100% stable because in the past it had bugs” and never touch it again, and it’s very hard to ‘disprove’ that claim because the people who have had problems are very few and far between - maybe you just haven’t hit their edge case yet. BTRFS has been around for a long time now, and at this point it’s probably going to be easier to just champion BcacheFS than try to remove the stigma around BTRFS.
If your server is a personal server I would feel free to use BTRFS if you feel the rest of its featureset fits your usecase. If you’re dealing with other people’s data/enterprise then I would try to use ZFS or something else, “just in case”.
Plz give me an hour long lecture on filesystems
I can give you the summary:
NTFS: what the fuck is this still doing in the wild. Malware maybe?
FAT: legacy FS for the lowest common denominator. Not good in any objective sense, but sometimes you are forced to use it.
ReiserFS: No one knows what ReiserFS actually does all we know is that the developer killed his wife and went to prison
Ext4: Old, stable, solid, and fast (even faster if you turn off journaling at the expense of reliability), but it’s missing some really nice modern features, like Copy-on-Write, snapshotting, and transparent compression
XFS: Ext4 for hipsters. Old, stable, fast, etc. There’s a recent push to try to make this a cool FS again with e.g. Stratis and reflinking support, but I don’t think it’s going to be the future. Still a great FS, but if you want XFS you’ll already know.
F2FS: Designed for optimal performance on flash storage, but generally it’s not good enough at that job to warrant using it over something else that has more features or is more reliable. Supports transparent compression, but oddly enough it doesn’t actually give you any extra free space when you compress. The compression is done only to reduce wear and tear on the cells.
ZFS: Gold standard FS, but incompatible licensing means it can’t be in the Linux kernel by default. It’s very stable, very fast, and likes to eat your RAM if you don’t tell it not to. Transparent ZSTD compression can be enabled to compress and decompress your files as you write/read, saving a lot of space. Its Copy-on-Write nature is more stable than traditional in-place editing because it won’t be vulnerable to power loss. As of OpenZFS 2.2 it also includes the reflinking feature, which will make file copies be instant within the same filesystem, reducing wear and tear. Notably if you’re making home-use RAID5/6 arrays it can feel very inflexible because it won’t let you add HDDs to your array on the fly (this was fixed on November 10th, 2023, but will not be released until OpenZFS 2.3 comes out). You’ll need to put some extra money into your home NAS setup to begin to see this filesystem shine, e.g. sacrificing half your disks for fast mirrored vdevs, which also allow reasonable growth. Buying a ton of RAM and maybe even an L2ARC SSD cache will also prevent wear and tear on your HDDs because most of your file reads will come from caches instead of the slow disks. This FS is designed for large data centers, and it’s really good at that.
BTRFS: ZFS for the rest of us. Contains a similar featureset to ZFS (Copy-on-Write, snapshots, transparent compression), but it’s better integrated into the Linux ecosystem. It’s generally worse in every other respect to ZFS, and it’s not as stable or time-tested either. It famously contains a “write-hole” bug that means RAID5/6 have the potential to eat your data, and so those are not recommended to be used. If you’re only considering a filesystem for a single drive (i.e. not a RAID), most of BTRFS’s downsides don’t matter. Many Linux distros are shipping with this FS as the default for the OS drive now, and it’s more or less being championed as “the future”.
BcacheFS: “The future v2”. Not even stable yet, that’s how you know it’s good. Contains unlimited features and zero bugs, 100% reliability, etc. All the best software is theoretical. We’ll see what happens when it’s fully mainlined into the Linux kernel.
MergerFS: fuck it what if filesystems weren’t even real. Transparently combine any other filesystems into a single logical filesystem. Usually used together with SnapRAID to make a more flexible home NAS RAID5/6 that can add or remove disks on the fly - this isn’t possible under ZFS and BTRFS shouldn’t be using RAID5/6 at all. Notably this configuration does not stripe data across disks, so even with an unmitigated disk failure you won’t lose the whole array. Disk performance won’t be as good as ZFS but flexibility and storage efficiency are probably a lot more important to a casual NAS owner.
So basically TLDR: BTRFS for home/OS use, MergerFS+SnapRAID backed by BTRFS disks for a budget home NAS, ZFS for a more expensive home NAS/server, and ZFS for enterprise.
I have not tried to use ZFS for home/OS but I’m guessing it’s not a good idea - most of ZFS’s advantages over BTRFS are regarding RAIDs, and poor Linux integration may cause headaches. Ext4/XFS is good for home/OS use if you have a real usecase, but otherwise BTRFS is generally just a better drop-in for most people these days. On HDDs you’re probably going to want to use ZFS or BTRFS because the transparent compression and copy-on-write nature will make the transfer speed not matter as much. On super-fast SSDs (e.g. for home/OS or a games drive), BTRFS might end up being slightly slower than Ext4/XFS, but transparent compression and copy-on-write will also prevent a ton of wear and tear on the physical SSD, so it really depends on your usecase.
Is the buggyness of BTRFS already gotten better? I fear to actually use it on my server as I’ve heard bad things about its stability.
If BTRFS is messing disks up in the wild today, I haven’t heard about it. You’ll find a few people saying that BTRFS messed up their disk in the past and they won’t touch it anymore, but Facebook runs all their stuff off BTRFS, and OpenSUSE+Fedora are shipping BTRFS by default to their users as well. We’d be hearing about it if there are real problems. Unfortunately, it’s easier to just say “BTRFS isn’t 100% stable because in the past it had bugs” and never touch it again, and it’s very hard to ‘disprove’ that claim because the people who have had problems are very few and far between - maybe you just haven’t hit their edge case yet. BTRFS has been around for a long time now, and at this point it’s probably going to be easier to just champion BcacheFS than try to remove the stigma around BTRFS.
If your server is a personal server I would feel free to use BTRFS if you feel the rest of its featureset fits your usecase. If you’re dealing with other people’s data/enterprise then I would try to use ZFS or something else, “just in case”.