Hello everyone. I’m going to build a new PC soon and I’m trying to maximize its reliability all I can. I’m using Debian Bookworm. I have a 1TB M2 SSD to boot on and a 4TB SATA SSD for storage. My goal is for the computer to last at least 10 years. It’s for personal use and work, playing games, making games, programming, drawing, 3d modelling etc.
I’ve been reading on filesystems and it seems like the best ones to preserve data if anything is lost or corrupted or went through a power outage are BTRFS and ZFS. However I’ve also read they have stability issues, unlike Ext4. It seems like a tradeoff then?
I’ve read that most of BTRFS’s stability issues come from trying to do RAID5/6 on it, which I’ll never do. Is everything else good enough? ZFS’s stability issues seem to mostly come from it having out-of-tree kernel modules, but how much of a problem is this in real-life use?
So far I’ve been thinking of using BTRFS for the boot drive and ZFS for the storage drive. But maybe it’s better to use BTRFS for both? I’ll of course keep backups but I would still like to ensure I’ll have to deal with stuff breaking as little as possible.
Thank you in advance for the advice.
This for sure. As a general rule of thumb, I use XFS for RPM-based distros like Red Hat and SuSE, EXT4 for Debian-based.
I use ZFS if I need to do software RAID and I avoid BTRFS like the plague. BTRFS requires a lot of hand holding in the form of maintenance which is far from intuitive and I expect better from a modern filesystem (especially when there are others that do the same job hassle free). I have had FS-related issues on BTRFS systems more than any other purely because of issues with how it handles data and metadata.
In saying all that, if your data is valuable then ensure you do back it up and you won’t need to worry about failures so much.
ZFS is great but I wouldn’t recommend it for single volume setups. I’ve never lost data with it but the parity has always been the saviour.
Never used BTRFS.
I avoid XFS due to performance reasons as most my systems are comprised of many smaller files which XFS isn’t great for. But the usage I’ve had with it, it’s been great
EXT4 is always my go-to for normal usage. Unless I need to be supporting older machines then it’s ext2/3.
Hey, thanks for the help. Can you elaborate on what kind of issues BTRFS gave you? What caused them, too?
Sure, I’ve used it both in Server and NAS scenarios. The NAS was where we had most issues. If the maintenance tasks for BTRFS weren’t scheduled to run (balance, defrag, scrub and another one i can’t recall), the disk could become “full” without actually being full. If I recall correctly it’s to do with how it handles metadata. There’s space, but you can’t save, delete or modify anything.
On a VM, its easy enough to buy time by growing the disk and running the maintenance. On a NAS or physical machine however, you’re royally screwed without adding more disks (if its even an option). This “need to have space to make space” thing was pretty suboptimal.
Granted now I know better and am aware of the maintenance tasks, I simply schedule them (with cron or similar). But I still have a bit of a sour taste from it, lol. Overall I don’t think it’s a bad FS as long as you look after it.
Thank you, that makes sense.
It needs a bit of periodic maintenance, the btrfs-assistant and btrfsmaintenance packages will set it up and from then on it’s automatic.
OpenSUSE, both Leap and Tumbleweed, use btrfs by default. Do you switch those to xfs during installation?
I’ve had btrfs snapshots pull me out of the fire multiple times on my home machines, but I don’t fully trust any file system at all, so I rsync stuff to two local network destinations and an off-site location as well. Those, too, have come in handy.
Yep, sure do. I’ve no real benefit for the features it adds, or I’m completely ignorant to the benefits is probably more accurate :)
For the things you’ve mentioned it is useful. I think the main thing I’ve been warned to never do with BTRFS is use it for RAID and to use md under it instead. That said, that could be old info and it may be fixed now.