The strongest argument in this 2025 ZimaOS feature-request thread was not simply “please add another filesystem.” Users wanted a storage model similar to Unraid: keep individually formatted disks of different sizes, present them as one logical pool, and add parity protection without converting the whole collection into a conventional striped RAID array.
Zima-Giorgio responded by asking why the upcoming JBOD option in ZimaOS 1.4.2 would not be enough and requested concrete real-world workflows. The replies make the distinction clear: JBOD can combine capacity, while MergerFS plus SnapRAID is attractive because it separates pooling from scheduled parity and lets users grow a home-media collection with dissimilar drives over many years.
Why Home NAS Users Asked for MergerFS and SnapRAID
Several participants described storage that grows piecemeal. One user had 3 TB, 6 TB, and 12 TB drives. Another described a chain where an 8 TB drive replaces a 6 TB disk in the main NAS, the displaced 6 TB disk moves to an archive system, and an older archive disk moves again into a home-lab server.
Traditional RAID can be awkward for that pattern because usable capacity and expansion rules often assume matched or carefully planned drives. The users wanted to preserve the value of existing disks rather than rebuild the entire array every time one larger disk is purchased.
MergerFS and SnapRAID Solve Different Problems
MergerFS is a union filesystem. It can make several independent filesystems appear under one logical mount point while the files still live on individual member disks.
SnapRAID is parity software. It calculates parity information from files on the data disks and can provide integrity checking. Parity synchronization is normally scheduled rather than written continuously like traditional RAID.
That separation is why the combination is popular for relatively static media collections: MergerFS provides the pool namespace, while SnapRAID provides recoverability from selected disk failures.
Why ZimaOS JBOD Is Not the Same Design
Current ZimaOS documentation describes JBOD as joining multiple drives into one continuous volume. It is a capacity option, not the same parity model users were requesting.
For current built-in choices, compare the RAID and JBOD options available in ZimaOS. JBOD is useful when the goal is simple pooled capacity, but it does not become SnapRAID merely because the member disks have different sizes.
The MergerFS Author Joined the Discussion
Trapexit, the developer of MergerFS, explained that CasaOS had historically used MergerFS for its “merge” storage feature. He had previously discussed deeper integration with IceWhale but said those conversations had not developed into a broader ZimaOS integration at that time.
He also framed a reasonable workload for MergerFS: files that are written once, read many times, and changed infrequently, where a logical pool of independent filesystems is more important than high random-write performance.
A CasaOS Merge Screen Appeared Later in the Thread
This screenshot is CasaOS evidence, not proof of a current supported ZimaOS MergerFS management page.
Why Users Consider SnapRAID Different from Real-Time Parity
The thread repeatedly focused on media archives where files do not change constantly. Scheduled parity lets unused disks sleep more often and avoids requiring every disk to participate in every read. Users also valued SnapRAID's integrity checks for detecting silent corruption.
The tradeoff is that changes made after the last parity sync are not protected by that parity snapshot. SnapRAID is therefore not a drop-in replacement for every RAID workload.
What IceWhale Actually Committed To
The official replies were cautious. Zima-Giorgio first asked users to explain why MergerFS and SnapRAID were irreplaceable compared with JBOD. In November 2025 he said the team had received the feedback and would reconsider the request.
That is not the same as a product commitment, roadmap date, or release announcement.
Current Status
Current ZimaOS storage documentation remains centered on single disks, JBOD, RAID, and ZFS-related built-in choices. There is no current official SnapRAID configuration page in the ZimaOS Storage UI.
Later community investigation in 2026 found a MergerFS binary on some ZimaOS systems and a community systemd-sysext project that packages MergerFS plus SnapRAID. Those are meaningful developments, but they are not the same thing as first-party SnapRAID support with a supported ZimaOS UI and lifecycle.
Choose the Storage Model by Workload
- Matched drives and continuous redundancy: use the ZimaOS RAID option that fits the failure tolerance you need.
- Simple capacity aggregation with no parity requirement: JBOD may be enough.
- Mixed-size, mostly static media with scheduled parity: MergerFS plus SnapRAID is the workflow users in this thread were requesting.
- Critical changing data: keep independent backups regardless of the array technology.
Parity Is Not a Backup
The request is about surviving drive failure, not accidental deletion, ransomware, or destruction of the entire server. A MergerFS/SnapRAID design still needs a separate backup plan for irreplaceable data.
MergerFS and SnapRAID FAQ
Did IceWhale announce official SnapRAID support?
No. The team requested use cases and later said it would reconsider the feedback.
Is ZimaOS JBOD equivalent to MergerFS plus SnapRAID?
No. JBOD is capacity aggregation; the requested design combines a union filesystem with parity synchronization.
Does ZimaOS have MergerFS-related community work?
Yes, but community binaries and sysext modules should not be described as an official SnapRAID management feature.
