I’d been using ZFS with Void linux on both my laptop and desktop for a couple of months. And ZFS is cool! But I’m thinking not great for my use case, especially for my laptop with it’s more constrained resources. Memory usage was a real problem, even after imposing low ARC limits. And the kernel module compile time was long enough to be a bit annoying, especially for a few kernels (I like to keep the last few around, to be safe) as it happens fairly often on a rolling release.
I switched the laptop to LUKS/btrfs a couple of days ago. And I’m thinking that was the correct choice for that. And now I’m considering doing the same for my desktop. As they seem comparable but btrfs is in-kernel and seemingly more system resource friendly. But before doing so I figured I’d ask the community about it. Maybe some important factors or features for either setup that I might not be considering.
Here’s the stuff I care about. All of which both offer, but I’m not an expert at either and I don’t know how equal they are.
- Disk encryption. For ZFS everything (except the EFI partition) is encrypted. I use ZFSBootMenu in this scenario. For the btrfs setup I have the kernel/initramfs on an ext2 partition. I do not store any decryption keys in the initramfs. I know grub can decrypt LUKS with limitations, but I prefer this setup. And it feels secure enough to me. Any pitfalls I’m missing?
- Pools/subvolumes
- Snapshots. ZFSBootmenu has an option to load a snapshot. For btrfs it looks like I’d need to create a subvolume from a snapshot, which in a recovery situation might mean doing this from recovery media. That’s ok, given this is an unlikely thing to encounter. But if anyone knows of an easier way, I’d love to hear it.
- CoW
- RAID 1
- Compression is nice, especially for the laptop
Edit: typo in title.
If you go for btrfs, be careful going backwards on kernel versions.
I had upgraded my kernel on Gentoo, which also happen to include a btrfs update. Booted up and found the latest kernel didn’t like something about my full disk luks encryption with RAID mirror setup (for the root partition, and unrelated to btrfs), so I decided to go back to the previous kernel. Big mistake.
My entire root partition got corrupted to hell. It mounted read only at first so I decided to try to go through regular repair steps. It got worse. Got to an eventual step that someone said could take a few weeks to restore (forgot the commands). This isn’t an option for my server. So with snapshots broken, unable to use the old and now new kernel due to corruption from attempting to go back to a previous kernel, I had to restore with a full partition clone backup I had created prior to the kernel upgrade… Also went back to ext4 again afterwards.
Btrfs treated me really well for a few years, and snapshots and performance are great, but once it hits a hiccup, you might in a world of trouble. Don’t think I’ve ever run into such a thing with ext4 over the years, which is why I reverted to it - not saying it’s immune to such things, but this is just me.
Not sure if zfs would have such a dramatic situation, but maybe something to consider about btrfs if you ever decide you’ll need the ability to go back a kernel version due to whatever reason.
Your comment as well as @stupid_asshole69@hexbear.net were really food for thought for me. stupid_asshole69 advising against, and yours as a cautionary tale.
This would be a complex stack to accomplish my goal. It occurs to me that it’d be mdadm (raid 1) > LUKS > btrfs since btrfs can’t do encryption which is right in the middle of that stack, so I couldn’t use it’s raid 1 functionality. If any of those pieces break, all the protection they would have otherwise provided me goes out the window.
And I’m not really worried about losing data. I already backup my personal files and most of my configs. The appeal with this kind of setup is the data redundancy and fairly quick recovery. But a partition clone like what saved you also works pretty well for that purpose. I don’t know what I’ll do just yet, but definitely taking all that in to consideration.