i've instaled opensuse tumbleweed a bunch of times in the last few years, but i always used ext4 instead of btrfs because of previous bad experiences with it nearly a decade ago. every time, with no exceptions, the partition would crap itself into an irrecoverable state
this time around i figured that, since so many years had passed since i last tried btrfs, the filesystem would be in a more reliable state, so i decided to try it again on a new opensuse installation. already, right after installation, os-prober failed to setup opensuse's entry in grub, but maybe that's on me, since my main system is debian (turns out the problem was due to btrfs snapshots)
anyway, after a little more than a week, the partition turned read-only in the middle of a large compilation and then, after i rebooted, the partition died and was irrecoverable. could be due to some bad block or read failure from the hdd (it is supposedly brand new, but i guess it could be busted), but shit like this never happens to me on extfs, even if the hdd is literally dying. also, i have an ext4 and an ufs partition in the same hdd without any issues.
even if we suppose this is the hardware's fault and not btrfs's, should a file system be a little bit more resilient than that? at this rate, i feel like a cosmic ray could set off a btrfs corruption. i hear people claim all the time how mature btrfs is and that it no longer makes sense to create new ext4 partitions, but either i'm extremely unlucky with btrfs or the system is in fucking perpetual beta state and it will never change because it is just good enough for companies who can just, in the case of a partition failure, can just quickly switch the old hdd for a new one and copy the nightly backup over to it
in any case, i am never going to touch btrfs ever again and i'm always going to advise people to choose ext4 instead of btrfs
I mean, unless you really like one of the weird bells and whistles btrfs supports ext4 is just faster and more reliable. If you don't have weird power user needs then anything else is a downgrade. Even ZFS really only makes a significant difference if you're moving around gigabytes of data on a daily basis. If you're on a BSD anyway feel free to go for it, but for most people there is no real benefit. Every other fancy new file system is just worse for typical desktop use cases. People desperately want to replace ext4 because it's old, but there's just really nothing to gain from it. Sometimes simple and reliable is good.
being able to revert a failed upgrade by restoring a snapshot is not a power user need but a very basic feature for everyday users who do not want to debug every little problem that can go wrong, but just want to use their computer.
ext4 does not allow that.
By using NixOS I can do this on ext4. Just reboot back to the previous image before the update. Not saying everyday users should be running nixos but there are other Immutable distros that can do the same.
will that also restore your data? what happens when a program updates its database structure with the update, and the old version you restore won't understand it anymore?
That is a good point. I've only had to rollback twice and nether time had any issues. But from my understanding of how it works, you are correct, the data wouldn't rollback.
I've learned this lesson with my Android phone a few years ago. There it was actually about sqlite databases of a system app (contacts I think?), but this can happen with other formats too. Worst is if it doesn't just error out, but tries to work with "garbage", because it'll possibly take much more time to debug it, or even realize that your data is corrupt.
You know file systems are not the only way to do that, right? Heck, Timeshift is explicitly designed to do that easily and automatically without ever even having to look at a command line. Backup before upgrade is a weird thing to cram into a file system.
by consuming much more space. but you're right, I did not think about it
I agree, but these are not really backups, but snapshots, which are stored more efficiently, without duplicating data. of course it does not replace an off site backup, but I think it has its use cases.
Copy on write, compression, and snapshots are really good whistles, though.
Copy on write is pretty overrated for most use cases. It'd be nice to have, but I don't find it's worth the bother. Disk compression and snapshots have had solutions for longer than btrfs has existed, so I don't understand why I'd want to cram them into an otherwise worse file system and call it an improvement. I will admit that copy on write and snapshots do at least have a little synergy together, but storage has gotten to be one of the cheapest parts of a computer. I'd rather just have a real backup.
Myself and many others have found lots of use in these features. If it's not important to you that's fine, but there ARE reasons many of us default to btrfs now.
Sure, if it's making your life easier or making you happy or whatever, then have it. Don't let me yuck your yum. I just think it doesn't provide any real benefit for most people. Am I not allowed to talk about my opinion?