Hi, coming from OMV I really like ZimaOS. Immediately bought got the + release, just to support the developers, I didn’t need any of the additional functionality. So thanks for all your work!
I’m struggling a bit though with the way ZimaOS handles it’s arrays. I have 2 4TB SSD’s in a mirror as my storage. In OMV I’ve always used a BTRFS mirror, for it has checksums and metadata. If one of the disks has errors, using the checksums BTRFS can (or should) still find the correct data, and repair the corrupt data.
Zima though creates a MD RAID1 mirror, and puts a ‘single disk’ BTRFS on top. This makes BTRFS unable to repair itself as it can never find out which data is the correct one when corruption occurs.
I found Zima can actually ‘enable’ BTRFS disks, and use them just fine. Will Zima in future allow full BTRFS arrays / disks in order to use it’s full potential? Would there be anything against using a BTRFS mirror right now?
1 Like
You’re correct in your understanding.
ZimaOS currently uses MD RAID1 with BTRFS on top, so while checksums can detect corruption, BTRFS can’t self-heal because it only sees a single block device.
A native BTRFS mirror (raid1 for data + metadata) would allow proper self-healing, which is what you’re used to from OMV.
You can use a BTRFS mirror manually on ZimaOS and it will mount and work, but it’s not managed by the ZimaOS storage UI, so you’d need to handle it outside the system and avoid modifying it via the UI.
It would definitely be a good feature request to support native BTRFS RAID in the future, as it unlocks the full benefits of the filesystem.
Well that’s what I did. I created a proper btrfs mirror instead of a single btrfs volume on top of md-raid. It works fine, and survives reboots, all services and dockers work just fine. But the second disk isn’t really recognised by Zima, showing the ‘setup your new disks’ button, even when it actually reports it’s in the btrfs array. So as long as you watch your steps in the GUI it works just fine (for now at least).
I really hope this gets proper support in the future. How to raise a feature request?
Yeah you’re basically right on the money here.
What you’ve done is the “proper” way BTRFS was meant to be used, it’s just that ZimaOS hasn’t caught up to that model yet. So it works… but the UI doesn’t really understand it, which is why it’s treating that second disk like it’s unused.
From what you described, you’ve already proven the important part, it survives reboots, Docker is happy, services are fine. That’s usually where things break if it’s not going to work.
The only thing I’d be careful of is exactly what you mentioned, the GUI. As long as you don’t let ZimaOS try to “set up” that second disk, you’re fine. The risk isn’t BTRFS, it’s the UI doing something destructive because it thinks the disk is free.
For the feature request, you’re already in the right place. Just open a new post in Insight & Feedback > ZimaOS and explain it pretty much how you did here. Real-world testing like yours actually helps a lot, because it shows it’s not just theory, it already works, it just needs proper support in the UI.
I’d frame it as:
“native BTRFS RAID1 support in storage manager so we get proper self-healing instead of MD + BTRFS”
That’s the key point.