I disagree. My partition is ext4, but Timeshift saved my ass when an upgrade went wrong. I just had to restore the system from a previous snapshot taken before the upgrade.
Of course updates can break stuff. What I don’t understand is why would you intentionally go for a less stable FS that can break and corrupt all files? It’s especially bad on old machines with limited space where full backups are not possible
I’m running it for over 3 years as complete linux moron with no issues whatsoever. It was default in openSUSE and its automatic snapshot feature saved my ass multiple times. I’ve heard everyone saying ext4 is super stable and I should use it, but I went with default and can’t complain.
Yes but why intentionally choose a worse option? Sorry but it’s not very smart imo.
And not having enough space is not an administrator failure. It’s usually budget issue. And are you saying that making apps bloated (like severely bloated) is ok and the user should always be blamed for having lower hardware?
Good that you mentioned that. Reminded me that I have an Arch Linux install here where I forgot that I did choose BTRFS during installation. Within maybe a month I noticed FS errors. Looked scary. Nervously searching for documentation was even more scary :
wiki.archlinux.org/title/btrfs#btrfs_check -> This article or section is out of date. (Discuss in Talk:Btrfs) Warning: Since Btrfs is under heavy development, especially the btrfs check command, it is highly recommended to create a backup and consult btrfs-check(8) before executing btrfs check with the --repair switch.
What is this? My beloved Arch Wiki is not 100% perfect!
Then found this :
WARNING: Using ‘–repair’ can further damage a filesystem instead of helping if it can’t fix your particular issue.
Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. E.g. some other software or hardware bugs can fatally damage a volume.
I figure this explains the popularity of BTRFS snapshot configurations. Luckily I had some backups :)
Filesystem snapshots won’t help, if the filesystem itself corrupts. But I’ve been using BTRFS for 6 years now and haven’t had a file system corruption, so mileage may obviously vary.
File system is a core component of any electronic system. Even if it’s just 1% less stable than other ones, it’s still less stable. Maybe it’s faster in some cases and supports better backups but ehh idk if it’s worth it. Losing documents is something you probably want to avoid at all costs
Yeah, but it isn’t noticeably “less stable” if at all anymore* unless you mean stable as in “essentially in maintenance mode”, and clearly good enough for SLES to make it the default. Stop spreading outdated FUD and make backups regularly if you care about your documents (ext4 won’t save you from disk failure either which is probably the more likely scenario).
not talking about the RAID 5/6 modes, but those are explicitly marked unstable
Well gtk if it’s really as stable as ext4. I will still stick to ext4 though because why change what already works well and tested on almost any machine you can possibly imagine?
I suppose by being more efficient, “using modern technology” (everything saving Google, Meta, Amazon etc. money and is thus extremely well funded, all server related stuff), is good for the environment.
If something runs faster on the same hardware, it may use less energy. It may also just be restricted in hardware usage, like not using multithreading.
Linux Distros shipping x86_64-v2 packages is a whole other problem…
I don’t know what’s the brand neW meta pick, but at least BTRFS over Ext4. BTRFS is just more stable and less corruptable than Ext4. Heck, fedora changed to it as default
To be fair, Fedora switching to something as default isn’t a good sign that you should start using it. I do agree, though, btrfs has come far enough to be a default choice for most people.
If you don’t actually have an opinion, just go with the default, ext4 really is a very good file system, but if you want to have an opinion and not go with the default, zfs is truly a fantastic file system.
XFS. It fills the same role as ext4 but it’s less likely to lose your data and that’s probably the most important part of a file system. Not that ext4 is bad or anything, but XFS is good. The only downside to XFS is you can’t shrink the filesystem size.
agreed. EXT4 for system, XFS for everything else (mostly large VM image files). when XFS is properly configured for the underlying drive array geometry, its a nearly perfect streamlined FS.
So i normally go with ext4, however windows can’t really access ext4 drives so you’d need to find a file system that both support if you want to access the drive/partition from windows. My drive with all the games is ntfs for example which works in Windows and Linux. (At least for normal storage, idk if you can boot linux from it although i wouldn’t see why not)
I was always wondering if there could be a small Linux partition for additional information of NTFS partitions, like meta data stored as a separate file (or database). And off course it would need some virtualization layer like WINE does for the file path mapping. Then it would be possible to use NTFS as system drive and for games.
Obviously this would be problematic and performance wouldn’t be great either (assuming), and it would complicate things for end user and developers too. But I was always thinking if this would be possible.
Mint doesn’t default to btrfs, but will use it if you so choose during install. And it integrates fantastically with Timeshift. I’ve set up daily and weekly snapshots and have peace of mind.
Compression might be useful in some cases, but the bulk of my data is already compressed or not much compressible (think videos, images, compressed archives, game assets). So the trade off doesn’t make much sense to me.
Just go with whatever is the default of your distribution.
That said I’ve come to love the automatic snapshots OpenSUSE gives me with BTRFS. I think they use snapper to automate that. It does a snapshot before and after every packet install, update or removal. And it has some system to delete snapshots that aren’t needed anymore but it always keeps enough to give you peace of mind, especially when you’re experimenting.
I should look into keeping some snapshots of my ~ as well. And I should implement that especially for my family.
Snapper is life saver. I don’t get it why nobody else use it by default, it’s so great. It saved me many times. My coworker, who happens to be kind of non-linux user forced there by MS bullshit, uses Ubuntu and she’s got to problems so many times, and all those would be couple clicks repair with Snapper…
Honestly, unless there’s some specific thing you’re looking for just use your distro’s default. If your distro doesn’t have a default I’d probably default to ext4. The way most people use their computers there’s really no noticeable advantage to any of the others, so there’s no reason not to stick with old reliable. If you like to fiddle with things just to see what they can do or have unusual requirements then btrfs or zfs could be worth looking into, but if you have to ask it probably doesn’t matter.
BTRFS for the OS partitions, ext4 for /home, tmpfs for /tmp. I rarely need to use snapshots, but I do use a rolling release. It’s one of those things you don’t need until you really fucking NEED it. Tumbleweed support is great - I can roll back a bad update in about as long as it takes to reboot.
Seeing that user Flatpaks are installed in the home folder, I see this as an interesting strategy. EXT4 still beats BTRFS in certain read/write benchmarks. My only problem being that you lose provisioning.
I don’t see a lot of people talking about this here, but BTRFS subvolume provisioning is probably the best reason to use BTRFS - and BCacheFS - not just CoW or snapshotting.
The old way, of having a set beginning and end of a partition, is like caveman technology to me now. Subvolumes are here to stay and I am happy about that.
If I need to do a little distrohop now, even though I wouldn’t (rpm-ostree rebase go brrrr), all I’d do is delete an recreate the “@” subvolume (or the root subvolume) without touching another partition or subvolume. All storage space is shared between subvolumes, basically, removing that boundary distinction between them, so I get to keep the files, permissions and meta data in my “@home” and my “@var” subvolumes, even though I get rid of the old “@” to replace it with a new one.
Therefore the idea of having storage that is reliant upon partitioning, ordering sectors one after another, having to defragment and keep strict separations between them is absolutely archaic to me. I’ll gladly take a slight performance hit just for the convenience of avoiding all that.
Ext4: It’s the most common used and most mature filesystem we have. You can use any rescue system without pitfalls, in case your system fails. Some other filesystems have edge cases or a special setup is required. I am not saying they are bad or so, just saying if you have to ask this question to a public forum, then it’s probably more safe to just use the default Ext4 system. It’s battle tested for ages.
If you’re on spinning rust with a modern CPU, compression actually helps your read/write speeds quite a bit. It’s faster for the CPU to compress/decompress then read/write less data because hard drives are so slow in comparison.
Add comment