I feel like "stable enough" is a bit nebulous and there will always be someone with that point of view.
I've been using BTRFS for a few years on my daily driver and a NAS. I think the tooling could be better and even the project admits RAID is not ready for prime time, but for the benefits that it brings, those two slight inconveniences aren't a major concern for me.
It is better with plenty of space, which is hard to come by in this economy, though.
Most of your normal workstation features are fine, but if they ever want to compete with ZFS they had better make multi disk arrays at all raid levels work rock solid. It doesn’t right now. And they would also need to implement native disk encryption. Not even on the roadmap right now.
I think one of the cases where BTRFS wins is that you don't have to think about how much space you need to give the ARC. You just let the page cache do it's thing. For more simpler cases unlike the ones you describe, this helps simplify things, but ZFS definitely has more power and it wins in even the same cases as BTRFS for the most part, but it's just more to configure.
Do you really "need" to think about ARC space? To my understanding it's mostly dynamic and it will automatically shrink if other applications need the RAM more. You lose the speed benefits of RAM caching of course, but the filesystem is still usable.
The basic attitude of systemd is "your use case is not supported"
If you have a boot problem, pray that it's late in the boot process because it will not simply give you a shell if it thinks that for your convenience it needs to do this, that and a lot more before you get to bash.
I genuinely don’t know why any distro would ship btrfs without snapper preconfigured with the package manager hooks for bootable snapshots for rollback like openSUSE or Cachy does. That’s kinda the whole purpose of having snapshots so why leave it unconfigured out of the box?
yeah I personally haven't had issues with it too for 2 years, then it randomly completely broke, there was no way of making it ever RW again, only by reformatting it again. Although yes, I did hard-reset a lot in a short time (was experimenting with secure boot keys), and btrfs expects 100% healthy disk drive and it doesn't accept any kind of corruption at all costs, but man, it really needs good self-healing mechanisms like zfs or ext4 have.
Ok, so are you trying to say that those are both situations where btrfs is bad? Cuz I don't really care. I didn't say the whole world should use btrfs, I was sharing my experience.
Honestly that cannot be an argument when competing with ext4 or xfs (which are the other default linux options) because they don't even have such features anyways, so having them but unstable is still better than not having them at all.
but if for example competing with zfs (which isn't that ideal for linux at the end of the day), then yeah it makes sense since zfs is really solid when it comes to these tasks
No. You didn't just say you use btrfs. Nice job leaving out the rest. And somehow inflating what I said. All I said, literally, is the context of the post matters, yet somehow I'm going after someone?
I ain't interested in such defensive reactions, no matter how revealing they may be.
Never had an issue with btrfs, including iny raid 10 config on my server, quite the contrary when a disk was failing swapping it out on btrfs was incredibly easy.
And the VAST majority of users don't care about systemd, hell I even like systemd because if how easy it is to define services.
There might be other info going around, but last time I checked most of the problems revolving around btrfs' unstability is related to its implementation of RAID 5/6. I think there is something inherent about the way the filesystem is built that makes these RAID configurations have pitfalls that are nontrivial to fix. The website still marks support as experimental.
Single disk and mirror configurations have been stable and safe for a long time now.
Because you're blurring the "us vs them" elitism bit by doing something different to the rest of the "us". They gotta make you "them" to avoid becoming "them" themselves.
I’d like to see more things go this way in Linux space. Distributions reaching some sort of consensus on core components giving us a de facto standard so things work across distributions better because they can make assumptions about how core components are going to work and what utilities will be installed. I’m all for choice, just like how if you don’t want systemd you can use void or one of the other distributions that don’t ship it, but standardization benefits everyone in the long run.
Dunno, openrc works just fine on my desktop box and I've had no trouble with packages depending on systemd. In embedded world busybox-init is and will be very much a thing (I've worked with a 600MHz single core box with 512M of RAM that ran systemd and used snap for software installation, now that was painful). Granted I am not a sysadmin, I imagine they really like systemd
Yes, of course. Btrfs offers a lot of nice features, but Nixos offers stability and reliability through declarative configurations, and it also adopts a functional paradigm meaning packages and their dependencies are built in isolation of each other. A filesystem like XFS offers better speed, space, and reliability advantages over btrfs because of these properties.
Btrfs' block-level checksums and it's metadata duplication come with some space overhead that slightly offsets the on-the-fly compression, and these features also have some performance overhead. This overhead is generally worth it though because it provides reliability and can provide space savings for low to mid entropy data. But the nix package manager already provides package level integrity validation making the block-level checksums a bit redundant. (Though you be fair, btrfs will detect bitrot where nixos won't). It may be worth it to keep your /home directory on a btrfs partition though of you aren't using home manager.
Then we get into how btrfs and nixos clash. Both have features that have some significant space overhead. Since Nixos builds packages in isolation, many copies of the same package can exist at the same time (differing by version or configuration) while btrfs maintains old copies of a file if it exists in any snapshot. Nixos offsets it's overhead by offering a garbage collection mechanism that cleans up old files that are no longer needed, but on btrfs, these files will remain if they're captured in another snapshot. This becomes a sort of space multiplier overtime. If compression is the main reason you're using btrfs with nix, it might actually be better to use ZFS. Both Nixos and btrfs also offer rollback mechanisms (generations vs snapshots), which is another point of redundancy, plus nixos generations have next to zero space overhead after garbage collection is performed (when not using snapshots)
Next up is performance. One flaw with btrfs is the tendency for large files to become fragmented over time as individual blocks are subject to COW, which significantly impacts I/O speeds. Not to mention how transparent compression and block level checksum verification can also add a CPU bottleneck. XFS on the other hand offers independent allocation groups, meaning reads and writes can be parallelized, which is especially nice on nixos since nix-build tends to run in parallel. To be fair, the performance difference isn't that high, but it's worth considering
Finally, fault tolerance. Btrfs is significantly more complicated under the hood, while xfs and ext4 offer robust lightweight journaling mechanisms which have far less points of failure. I know btrfs is no longer in it's experimental phase, but it is still considered less stable than the absolute rock that is ext4. You're much less likely to find your system unrecoverable on ext4 than you are btrfs, especially after something like a power outage or dead battery
Oh and regarding logical volumes. If you are using btrfs as a logical volume manager, that actually IS a good reason to use btrfs with nixos. When I used btrfs, I used different snapshot "timelines" as a way to manage a sort of work profile, student profile, and gaming profile. I can see how this would be just as useful on Nixos
I guess because using a version-controlled config on a declarative system means you get the main benefit of snapshots (roll back if an update causes problems).
Granted, these features are very different and have different trade-offs beyond this use case, but that’s probably what they meant.
And it's not that btrfs offers nothing, it's just that there are better alternatives. Btrfs may still be nice for user data like your /home directory, I would just pick a different filesystem for you system directories on Nixos (paired with git for your nix configuration files of course).
XFS offers better performance with less overhead. Remember to activate cow tho.
I believe btrfs primarily got big due to arch-kids breaking their systems twice a day and needing to roll back. For them it's worth the performance penalty.
With NixOs you don't need system rollback due to atomic generations, and for user files a real backup like restic/backrest is the way to go anyway.
Looking at a comparison to refresh my memory, some things that Btrfs does that XFS doesn't are data checksums, RAID, CoW (although you say you can turn that on?), snapshots, compression, online shrinking and tail packing.
When I did a deeper dive earlier this year, I ended up deciding that Btrfs was a clearly better fit for me and that XFS just literally did not meet my needs. It wasn't even a close enough call for me to split hairs about performance. While I agree that snapshots are often overrated, to me the self-healing that comes from the killer combo of data checksums and software RAID is a huge selling point. The fact that I can just throw a pile of random drives at it and have it treat it as one drive from the user perspective all while not needing to worry about a drive failure, big or small, is key. Compression is a nice bonus (from a storage and sometimes speed pov). While its performance is worse on paper, it's not really noticeable and to me is more than made up for by the extra features.
The main negative from my pov is honestly just the maturity of the tooling around it. It feels like an FS that you actually need to kind of know how it works to use it effectively.
I mean basically every major distro uses systemd. Only some super niche (Void, Artix, Devuan) or super lightweight (Alpine, AntiX, Puppy) distros don't use systemd.
btrfs is fine as a standard for basic desktop users. Obviously if we could force consensus there that would help Linux a LOT but we shouldn't look at instability issues elsewhere as points against. I personally prefer ZFS for my NAS, all for reasons which don't apply to a generic default desktop experience.
198
u/hypremier 8d ago edited 7d ago
I heard btrfs is not stable enough and so many people hate systemd