| Feature | ZimaOS JBOD | MergerFS |
|---|---|---|
| How it works | Combines disks at the block level into one big volume | Merges folders at the filesystem level |
| Where files live | Could be anywhere inside the spanned block device | Always stays on the specific disk where it was created |
| If a disk fails | You lose all files stored on that disk’s portion of the span; sometimes the whole span becomes unreadable | You lose only the files physically on the failed disk; other disks remain fully readable |
| Can you pull a disk and read it elsewhere? | Usually no (depends on how ZimaOS implements JBOD) | Yes, because each disk keeps its native filesystem |
| Risk level | Higher | Lower |
| Flexibility | Low | Very high |
| Best use case | Temporary scratch storage, non‑critical data | Home servers, media libraries, mixed‑size disks, safe expansion |
I would be nice if MergerFS was native to Zima OS
I honestly think this is one of the best simple explanations of the difference I’ve seen so far.
For most home server users, especially on ZimaOS, the biggest advantage of MergerFS is not performance, it’s fault isolation and recoverability.
With traditional JBOD/span setups, the storage becomes one logical structure at a lower level, so when metadata or one disk goes bad, things can get messy very quickly. We’ve already seen quite a few storage/mount related edge cases in the 1.6.x series.
With mergerfs:
- each disk stays independently readable
- disks can be moved to another Linux machine and mounted directly
- mixed disk sizes work naturally
- expansion is simple
- a single disk failure does not usually cascade into a larger storage failure
That model fits media servers, backups, Immich libraries, and gradual home-lab expansion much better.
A good real-world comparison is:
- JBOD/span = “one giant basket made from multiple disks”
- MergerFS = “multiple normal disks presented through one smart window”
The second model is usually much safer for average users.
I could definitely see native MergerFS support being a huge win for IceWhale Technology, especially paired with:
- snapraid support
- proper disk health awareness
- UI-based pool expansion
- safer mount management
- clear per-disk file visibility
That would make ZimaOS extremely attractive for home media/storage users who want flexibility without jumping fully into something like TrueNAS SCALE or Unraid.
I’ve actually been using MergerFS already on my setup and honestly it’s been great so far.
For a home server/media server setup it feels much safer and more flexible than traditional JBOD/SPAN. I really like that every drive stays independently readable and that adding different sized drives is super easy.
The biggest advantage for me is peace of mind:
if one drive fails, the other drives and data are still accessible without the whole storage pool becoming a mess.
I think native MergerFS support in ZimaOS would be a huge win for many home users, especially combined with something like SnapRAID.
That’s been my experience too.
One thing I really like about MergerFS is that it behaves much closer to how home users actually expect storage to work:
- each drive remains a normal standalone filesystem
- disks can be removed and read independently
- mixed-size expansion is easy
- recovery is far less stressful if something fails
For media servers and long-term home storage, that “fault isolation” is a huge advantage compared to traditional JBOD/SPAN approaches.
Pairing MergerFS with SnapRAID would honestly make a lot of sense for ZimaOS:
- flexible expansion
- parity protection
- lower risk during disk failures
- easier recovery paths
- better fit for mixed consumer drives
Especially now that many users are running large media libraries, Immich, backups, and AI datasets, I think this approach aligns much better with real-world home server usage.
With the price of NAS HDD right now I just can’t afford to drop 2K on hdd’s all at once. Slowly adding them as I need and being able to include snapRAID for peace of mind would be great once my storage grows