01-04-2026, 01:27 PM
The JMB585 itself is normally a stable controller
It is widely used in smaller NAS and DIY builds. Under normal conditions it handles SATA traffic well, and many systems run it for years without problems. The trouble begins when:
• all 5 ports are saturated at once
• heavy mixed read and write workloads are running
• the firmware or power delivery is marginal
When that happens, some units appear to trigger a controller reset. That instantly drops all drives for a moment.
What that means for ZFS
ZFS expects the underlying hardware to be stable. If the controller resets mid write, ZFS can write bad data to disk before it has a chance to generate checksums. When ZFS later verifies the checksum, it sees corruption — but at that point the corrupted data is already committed.
This is not a ZFS bug. It is a hardware level issue.
Is it widespread
Hard to say yet. There are multiple independent reports, and they are all describing the same symptoms, which makes this worth attention. But not every user is seeing it, which suggests a batch, firmware, or board level variance.
If data integrity is your top priority
At the moment the safer options are:
• Aoostar WTR Max
• Topton / Hunsn variants with ASM1166
• Any board with an onboard Intel, AMD, or LSI based SATA solution
These have not shown the same reset behaviour.
Thanks again for flagging this.
It is widely used in smaller NAS and DIY builds. Under normal conditions it handles SATA traffic well, and many systems run it for years without problems. The trouble begins when:
• all 5 ports are saturated at once
• heavy mixed read and write workloads are running
• the firmware or power delivery is marginal
When that happens, some units appear to trigger a controller reset. That instantly drops all drives for a moment.
What that means for ZFS
ZFS expects the underlying hardware to be stable. If the controller resets mid write, ZFS can write bad data to disk before it has a chance to generate checksums. When ZFS later verifies the checksum, it sees corruption — but at that point the corrupted data is already committed.
This is not a ZFS bug. It is a hardware level issue.
Is it widespread
Hard to say yet. There are multiple independent reports, and they are all describing the same symptoms, which makes this worth attention. But not every user is seeing it, which suggests a batch, firmware, or board level variance.
If data integrity is your top priority
At the moment the safer options are:
• Aoostar WTR Max
• Topton / Hunsn variants with ASM1166
• Any board with an onboard Intel, AMD, or LSI based SATA solution
These have not shown the same reset behaviour.
Thanks again for flagging this.