Ext4, my needs are simple and in all the years I've been using extX, never had a problem
Same. I tried btrfs and ended up with a corrupted drive. I've never had ext4 fail on me in a way that wasn't recoverable. Boring and safe are features I like in my filesystems.
ZFS. I want snapshots, volumes, encryption etc. btrfs fucked me over too often. Also I prefer the semantics of the zfs and zpool utils and the way mount points are handled. Thanks to ZFSBootMenu I can even have /boot as a zfs volume and have it therefore incluced in my snapshots. And did I mention that all of that is encrypted? Anyway. Love it.
ZFS is really like the god filesystem: it supports basically everything you might want out of the box. Compression, encryption, snapshots, CoW, RAID, checksumming, casefolding/case insentivity, block volumes, you name it.
You can get compression, snapshots and CoW with btrfs and some basic RAID, but not encryption. You can get encryption with ext4 but pretty much nothing else. Gotta do LUKS and LVM if you want volume management, mdadm if you want any sort of RAID. f2fs does pretty much nothing but flash friendly storage.
Itβs a shame it canβt be included in the mainline kernel. Especially over what seems to be a legal technicality.
ZFS for RAID array and BTRFS for root is the way to go!
Btrfs because I've had constant issues with zfs in multiple different times.
Everyone praises zfs so I'm sure it's something I'm missing, but I've had very little issue with btrfs, other than it's incomplete feature set.
What kind of issues?
Its mostly that due to licensing issues it can't be included in the Linux kernel like btrfs and thus is prone to breaking at very in-opportune times.
IMHO both are fine, but btrfs is more hassle free and good enough (tm) for hobby self-hosters.
He's talking about kernel taint. That is annoying in Linux.
I have enough to think about without the damn file system getting complicated. So plain old ext4. It's stable, it works it's great.
I used btrfs once and it went really badly. When it gets corrupted it refuses to even let you mount read only. The documentation isn't good and you end up finding obscure wiki's with big warnings to only run these commands if you know what you're doing - but of course I don't, there's no where to learn it and the only people who do know are the developers who wrote the file system. No thanks! It holds your data captive, so you better have some spare time and some backups. Never again.
That's my issue with btrfs as well. If you can't recover a file system when something goes wrong it isn't production ready imo.
Totally agree, plus it's 14 years old, and at this point I think it's fair to just give up on it.
ZFS raidz1 or raidz2 on NetBSD for mass storage on rotating disks, journaled FFS on RAID1 on SSD for system disks, as NetBSD cannot really boot from zfs (yet).
ZFS because it has superior safeguards against corruption, and flexible partitioning; FFS because it is what works.
What are the advantages of raid10 over zfs raidz2? It requires more disk space per usable space as soon as you have more than 4 disks, it doesn't have zfs's automatic checksum-based error correction, and is less resilient, in general, against multiple disk failures. In the worst case, two lost disks can mean the loss of the whole pack, whereas raidz2 can tolerate the loss of any 2 disks. Plus, with raid you still need an additional volume manager and filesystem.
@Hopfgeist Speed on large spinning disks. Faster rebuilds. Less chance of complete failure because or URE.
Btrfs, because of compression. And I've never had any issues with it.
Right now just ext4 because I'm just hosting a minecraft server and a website that's not even up right now. I'm thinking about btrfs when I build my next system. Transparent file compression and sub-volumes looks appetizing
Zfs I lost so much data trying to use btrfs. And zvols are neat.
ext4 on boot drives just because it's so standard and uncomplicated. Data drives either xfs or btrfs, depending on how froggy I'm feeling when I set it up. I don't use the fancy features of the filesystem. Hell, I barely even use lvm. I find all that stuff just gets in the way. I just want to put files on disk.
I've tried zfs, and it seems nice, but when you have a lot of storage, you need to have a lot of RAM to actually make it useful, and I don't.
I love em all, especially btrfs.
But I have to stay away from xfs. Had so many weird issues with it that made no sense.
Zfs for data, vms, lxc, file server.
Ext4 for basically root partitions, maybe ufs on the non-jailed freebsd.
Old policy, separate data and OS so you can switch quickly, had it since dos and never really switched.
Zfs is perfect but heavy, especially the arc so try not to wave it at everything. Ext4 is good enough for anything where I really don't care about integrity.
Tried btrfs but zfs is awesome because when I'm done I can always send a snapshot from my workers to the main fileserver with zfs-send and keep it around. Zfs-send/receive really change the game, as does zfs's trusted raid and zlog/l2arc which makes spinning rust fly.
Btrfs. been 7 years no issues. Those with lots of issues may have setup an unsupported Raid configuration.
Just ext4 pooled together with mergerfs for my media files. Seems to fit my use perfectly.
ext4 on an mdadm raid. It works well enough, and supports growing your array.
Although if I rebuilt this from scratch, I would skip mdadm and just let minio control all the drives. Minio has an S3 compatible API, which I'd then mount into whatever apps need it.
Love MinIO but itβs not a filesystem and mounting object storage as a filesystem is not a great experience (speaking from commercial experience).
Same experience here. S3 is essentially a key/value store to simply put and retrieve large values/blobs. Everything resembling filesystem features is just convention over how keys are named. Comminication uses HTTP, so there is a lot of overhead when working with it as an FS.
In the web you can use these properties to your advantage: you can talk to S3 with simple HTTP clients, you can use reverse proxies, you can put a CDN in front and have a static file server.
But FS utils are almost always optimized for instant block based access and fast metadata responses. Something simple like a find will fuck you over with S3.
Love mdadm, it's simple and straightforward.
Ext4 because it is rock solid and a reasonable foundation for Gluster. Moving off of ZFS to scale beyond what a single server can handle. I would still run ZFS for single-server many-drive situations, though MDADM is actually pretty decent honestly.
btrfs on my gentoo box because I couldnβt be bothered to set up ZFS, although I love it.
ZFS on my proxmox boxes.
BTRFS on OS volumes for the rollback features and ext4 for data volumes because I have never had total data loss from ext3 or ext4.
For most systems, ext4 because it seems stable and uncomplicated.
For my NAS and big data, ZFS. People whose opinions I trust recommend it, and to the best of my technical ability to evaluate said things, the claims make sense and seem to be extremely beneficial against the threats I perceive to my data.
Ext4 for my root filesystem, although I've been eyeing BTRFS for a while now as a replacement.
BTRFS for all my arrays and auxillary drives - aside from one oopsie where some drives had power issues and retained corrupted data (BTRFS managed to recover everything just fine), it's been a fine experience I guess.
Judging by the amount of responses mentioning being burnt by data loss, I wouldn't be surprised if most of these were probably caused by running "btrfs fsck" π±π
I am also pretty interested in btrfs. I recently redid my laptop and did btrfs for everything there. No btrfs on my server yet though. Ext4 is just really optimal for data recovery. Maybe if I redo my server sometime in the future I'll start with btrfs.
I have been using #btrfs for years now. I have not had any issues with it.
Zfs on freebsd file server, for the error checking, error correction and flexibility.
FFS everywhere else, because I'm an OpenBSD guy. I don't love FFS, but it works.
XFS for the moment, but transitioning towards ZFS. I'd never touch btrfs again, it simply is not resilient or as recoverable as a quality file system should be.
Ext4 (for my laptop and stuff) and ZFS (as mirrors or raidz2 for my proxmox host and data).
ZFS on file server, fully luks encrypted btrfs on desktop, and probably ext4 or whatever is default on the buntus for laptop and work desktop.
ZFS on freenas/truenas has been rock solid for 10+ year raid. I love working with btrfs snapshots and the ease of adding drives on demand to expand. I don't think much about ext4 on those systems.
jfs+lvm on personal machines, ceph on storage, I used to use zfs on solaris and freebsd but haven't touched it in linux (there isn't any good reason, and I prefer to not break licensing)
ZFS on server. Btrfs on laptop.
Btrfs except for /boot. Boot is ext4 but all other volumes are btrfs. Important stuff like docker, lxc or VMs are on subvolumes for quick snapshots just in case
I tend to use btrfs on single disks for reasons of snapshots (that I never use...), subvolumes, CoW, etc.
For my multi-disk needs (and single-disk stuff when it gets mainlined), bcachefs is my file system of choice. I'm currently running a 90tb spinning rust + 24tb metadata and cache on ssds on my archive / nas box.
Ext4, my needs are simple and in all the years I've been using extX, never had a problem
Same. I tried btrfs and ended up with a corrupted drive. I've never had ext4 fail on me in a way that wasn't recoverable. Boring and safe are features I like in my filesystems.
ZFS. I want snapshots, volumes, encryption etc. btrfs fucked me over too often. Also I prefer the semantics of the
zfsandzpoolutils and the way mount points are handled. Thanks to ZFSBootMenu I can even have/bootas a zfs volume and have it therefore incluced in my snapshots. And did I mention that all of that is encrypted? Anyway. Love it.ZFS is really like the god filesystem: it supports basically everything you might want out of the box. Compression, encryption, snapshots, CoW, RAID, checksumming, casefolding/case insentivity, block volumes, you name it.
You can get compression, snapshots and CoW with btrfs and some basic RAID, but not encryption. You can get encryption with ext4 but pretty much nothing else. Gotta do LUKS and LVM if you want volume management, mdadm if you want any sort of RAID. f2fs does pretty much nothing but flash friendly storage.
Itβs a shame it canβt be included in the mainline kernel. Especially over what seems to be a legal technicality.
ZFS for RAID array and BTRFS for root is the way to go!
Btrfs because I've had constant issues with zfs in multiple different times.
Everyone praises zfs so I'm sure it's something I'm missing, but I've had very little issue with btrfs, other than it's incomplete feature set.
What kind of issues?
Its mostly that due to licensing issues it can't be included in the Linux kernel like btrfs and thus is prone to breaking at very in-opportune times.
IMHO both are fine, but btrfs is more hassle free and good enough (tm) for hobby self-hosters.
@poVoq @vext01 so no issues.
He's talking about kernel taint. That is annoying in Linux.
I have enough to think about without the damn file system getting complicated. So plain old ext4. It's stable, it works it's great.
I used btrfs once and it went really badly. When it gets corrupted it refuses to even let you mount read only. The documentation isn't good and you end up finding obscure wiki's with big warnings to only run these commands if you know what you're doing - but of course I don't, there's no where to learn it and the only people who do know are the developers who wrote the file system. No thanks! It holds your data captive, so you better have some spare time and some backups. Never again.
That's my issue with btrfs as well. If you can't recover a file system when something goes wrong it isn't production ready imo.
Totally agree, plus it's 14 years old, and at this point I think it's fair to just give up on it.
ZFS raidz1 or raidz2 on NetBSD for mass storage on rotating disks, journaled FFS on RAID1 on SSD for system disks, as NetBSD cannot really boot from zfs (yet).
ZFS because it has superior safeguards against corruption, and flexible partitioning; FFS because it is what works.
@Hopfgeist @sam I prefer RAID10 on rust.
What are the advantages of raid10 over zfs raidz2? It requires more disk space per usable space as soon as you have more than 4 disks, it doesn't have zfs's automatic checksum-based error correction, and is less resilient, in general, against multiple disk failures. In the worst case, two lost disks can mean the loss of the whole pack, whereas raidz2 can tolerate the loss of any 2 disks. Plus, with raid you still need an additional volume manager and filesystem.
@Hopfgeist Speed on large spinning disks. Faster rebuilds. Less chance of complete failure because or URE.
Btrfs, because of compression. And I've never had any issues with it.
Right now just ext4 because I'm just hosting a minecraft server and a website that's not even up right now. I'm thinking about btrfs when I build my next system. Transparent file compression and sub-volumes looks appetizing
Zfs I lost so much data trying to use btrfs. And zvols are neat.
ext4 on boot drives just because it's so standard and uncomplicated. Data drives either xfs or btrfs, depending on how froggy I'm feeling when I set it up. I don't use the fancy features of the filesystem. Hell, I barely even use lvm. I find all that stuff just gets in the way. I just want to put files on disk.
I've tried zfs, and it seems nice, but when you have a lot of storage, you need to have a lot of RAM to actually make it useful, and I don't.
I love em all, especially btrfs. But I have to stay away from xfs. Had so many weird issues with it that made no sense.
Zfs for data, vms, lxc, file server.
Ext4 for basically root partitions, maybe ufs on the non-jailed freebsd.
Old policy, separate data and OS so you can switch quickly, had it since dos and never really switched.
Zfs is perfect but heavy, especially the arc so try not to wave it at everything. Ext4 is good enough for anything where I really don't care about integrity.
Tried btrfs but zfs is awesome because when I'm done I can always send a snapshot from my workers to the main fileserver with zfs-send and keep it around. Zfs-send/receive really change the game, as does zfs's trusted raid and zlog/l2arc which makes spinning rust fly.
Btrfs. been 7 years no issues. Those with lots of issues may have setup an unsupported Raid configuration.
Just ext4 pooled together with mergerfs for my media files. Seems to fit my use perfectly.
ext4 on an mdadm raid. It works well enough, and supports growing your array.
Although if I rebuilt this from scratch, I would skip mdadm and just let minio control all the drives. Minio has an S3 compatible API, which I'd then mount into whatever apps need it.
Love MinIO but itβs not a filesystem and mounting object storage as a filesystem is not a great experience (speaking from commercial experience).
Same experience here. S3 is essentially a key/value store to simply put and retrieve large values/blobs. Everything resembling filesystem features is just convention over how keys are named. Comminication uses HTTP, so there is a lot of overhead when working with it as an FS.
In the web you can use these properties to your advantage: you can talk to S3 with simple HTTP clients, you can use reverse proxies, you can put a CDN in front and have a static file server.
But FS utils are almost always optimized for instant block based access and fast metadata responses. Something simple like a
findwill fuck you over with S3.Love mdadm, it's simple and straightforward.
Ext4 because it is rock solid and a reasonable foundation for Gluster. Moving off of ZFS to scale beyond what a single server can handle. I would still run ZFS for single-server many-drive situations, though MDADM is actually pretty decent honestly.
btrfs on my gentoo box because I couldnβt be bothered to set up ZFS, although I love it.
ZFS on my proxmox boxes.
BTRFS on OS volumes for the rollback features and ext4 for data volumes because I have never had total data loss from ext3 or ext4.
For most systems, ext4 because it seems stable and uncomplicated.
For my NAS and big data, ZFS. People whose opinions I trust recommend it, and to the best of my technical ability to evaluate said things, the claims make sense and seem to be extremely beneficial against the threats I perceive to my data.
Ext4 for my root filesystem, although I've been eyeing BTRFS for a while now as a replacement.
BTRFS for all my arrays and auxillary drives - aside from one oopsie where some drives had power issues and retained corrupted data (BTRFS managed to recover everything just fine), it's been a fine experience I guess.
Judging by the amount of responses mentioning being burnt by data loss, I wouldn't be surprised if most of these were probably caused by running "
btrfs fsck" π±πI am also pretty interested in btrfs. I recently redid my laptop and did btrfs for everything there. No btrfs on my server yet though. Ext4 is just really optimal for data recovery. Maybe if I redo my server sometime in the future I'll start with btrfs.
@stephenc @lemann
I have been using #btrfs for years now. I have not had any issues with it.
Zfs on freebsd file server, for the error checking, error correction and flexibility.
FFS everywhere else, because I'm an OpenBSD guy. I don't love FFS, but it works.
XFS for the moment, but transitioning towards ZFS. I'd never touch btrfs again, it simply is not resilient or as recoverable as a quality file system should be.
Ext4 (for my laptop and stuff) and ZFS (as mirrors or raidz2 for my proxmox host and data).
ZFS on file server, fully luks encrypted btrfs on desktop, and probably ext4 or whatever is default on the buntus for laptop and work desktop.
ZFS on freenas/truenas has been rock solid for 10+ year raid. I love working with btrfs snapshots and the ease of adding drives on demand to expand. I don't think much about ext4 on those systems.
jfs+lvm on personal machines, ceph on storage, I used to use zfs on solaris and freebsd but haven't touched it in linux (there isn't any good reason, and I prefer to not break licensing)
ZFS on server. Btrfs on laptop.
Btrfs except for /boot. Boot is ext4 but all other volumes are btrfs. Important stuff like docker, lxc or VMs are on subvolumes for quick snapshots just in case
I tend to use btrfs on single disks for reasons of snapshots (that I never use...), subvolumes, CoW, etc.
For my multi-disk needs (and single-disk stuff when it gets mainlined), bcachefs is my file system of choice. I'm currently running a 90tb spinning rust + 24tb metadata and cache on ssds on my archive / nas box.