Openmediavault RAID1 NAS Performance Test on Banana Pi

29 41406
I have just completed the RAID1 NAS Performance Test on Banana Pi using Openmediavault and wanted to share the result and report.
Openmediavault RAID1 NAS Performance Test on Banana Pi.pdf (1.79 MB, Downloads: 1070)
Great info! Thanks!

The performance is horrible and why do you use RAID-1 when you're not willing to test the behaviour when your RAID setup will fail? Please remove one disk, replace it with another 3 TB disk and report back. And of course: Most of the cheap NAS devices available will also totally suck.

Nice work!

Edited by tkaiser at Thu Jan 15, 2015 03:53
cyryllo replied at Wed Jan 14, 2015 03:28
Nice work!

Really? Advertising RAID-1 (which is nearly totally useless in home/SOHO environments where availability doesn't matter -- if one want to waste HDDs then it would be better to use them for backup and not failure prone and therefore useless redundancy) without even testing/demonstrating the downsides of this approach with inapproriate hardware?

Where is the report about a RAID rebuild? Why does one want to use RAID when it's not about failure of one component? How can one come to a conclusion unless the main purpose of the setup in question has been successfully tested? Who's interested in the bad performance of a setup that will totally fail when its main feature would be needed (generating uninterruptible access to the data in case a HDD fails -- preventing data loss should be done implementing backup, RAID won't help here at all!). Where is the positive test report for a failing RAID setup? How long does the rebuild take? How's performance while rebuilding the RAID?

Others tried that already and that's the status of RAID with el cheapo PMs on the Banana:

Clearly the RAID-1 on the BPi with PM does not work. After about 5% sync completion of just 160GB volumes it gets locked up. The system cannot even be halted properly  and the only option is a hard reset

Cheap RAID implementations on unreliable hardware are always crap. They lead to wrong assumptions ('data safety' -- LOL!) and data losses.

some answers to the questions above:

- the reasoning of choosing RAID1 was explained in the report … on page 1.
- a resync situation was described in the report as well… cf. page 8. I did not add an extra picture showing the resync as it is the similar to the resyncing picture on page 7. and I did not have a 3rd spare disk avail. otherwise I would have done a test on RAID5 ;-)  
- RAID1 resync (same disk cf. above) was performed by a few commands as recommended in the OMV forums.
- the resync took 26hours and completed successfully - was mentioned in the report at page 8.
- performance during re-build (have not thought about this) - was not measured but the system was much responsive and the CPU load during resync was very low as decribed.
- overall the system behaved exactly the same as with other OMV NAS I used before.

My proposal to go further is in two directions:

1) Dedicated discussion about what NAS/xRAID architectures are feasible in the context of Banana Pi.

2) Investigate further to make Banana Pi even better working with sata port multipliers (A20 sata bug, CBS/FBS support, improved drivers,...)
    If others had problems building RAID so far, the report may be of some help though.

At least I learned also while doing this test ... which is also one of the purposes of the the Banana Pi project ;-)

Edited by tkaiser at Thu Jan 15, 2015 07:11
bpiuser replied at Thu Jan 15, 2015 05:36
At least I learned also while doing this test ... which is also one of the purposes of the the Banana Pi project

Ok, then the most important lesson to learn is: Don't do this. It's slow, unreliable and costly (compared to an also crappy PC based RAID implementation that features enough native SATA ports eg. outlined in this thread). If you add the costs for the Port Multiplier, PSU and enclosure you will simply realize that you get a more reliable implementation being many times faster and being less expensive using a cheap PC based Mini-ITX solution that features at least a few SATA ports providing superiour speed.

And RAID in such an environment makes no sense at all. It's only about availability ("business continuity") and realiability. Which is not possible with unreliable hardware. You would have to repeat resync/recover tests at least hundred times to know whether your setup with the cheap PM will succeed each and every time an array has to be rebuilt. While this might not be true for another user buying a different (clone of) JMB321 on aliexpress, trusting in your published experiences, believing he has done something regarding data safety (many inexperienced users do so!) and losing the whole array the first time a disk (or the PM... or the single SATA port) fails.

That's the problem with home/SOHO RAID: You trust a setup you can't trust in unless you've proven the realibility many many times. I've seen so many RAID setups failing the last two decades that I want to prevent people from trusting in those unreliable setups. Especially when the whole approach is totally useless. Why RAID-1 when you don't need availability (if you need availability I would consider using a server platform and not a tablet grade hardware like a SBC)? Other RAID levels would make some sense if you want to concatenate the capacity of different disks. But while RAID-5 isn't sufficient for TB HDDs since years, RAID-6 would mean really crappy performance with HDDs behind a cheap PM and RAID-6 in mdraid was broken for almost 5 years without anyone noticing it: (and RAID-6 in btrfs is still not ready for deployment)

Conclusion: If you want it slow, error/failure prone and you like bit rotting as well as frequent data losses... then play with RAID, Port Multipliers, 'servers' without ECC RAM, and so on. Otherwise accept that the minimum requirements for home/SOHO RAID are ECC RAM and the necessary count of SATA connectors as well as a storage implementation that features end-to-end data integrity and can deal way better with disk failures than the brain dead 'resync every unused block' approach mdraid on Linux provides. Then it's time to have a look at HP's N54L (or better) and go with ZFS unless btrfs is ready...

And please don't get me wrong. I appreciate your work. But since it let inexperienced user trust in the idea of home/SOHO RAID (and most of the times they will associate the whole approach with 'data safety' which is impossible using redundancy) it might lead to data losses. Therefore I again and again strongly argue against such RAID approaches.

For OMV/NAS users it would be a much better solution if efforts were put into a real backup solution utilizing versioning and rotated media (or even better a remote location consisting of a second Banana with HDD). Would be way better than crappy RAID implementations. But since RAID is cool and backup not... this won't happen...

@tkaiser: pls. consider the facts first e.g. about the existence of elaborate backup solutions before advising what people should do and where to invest their time.;-) Don´t get me wrong but your pushy style is not perceived being adequate but insolent.  

Edited by tkaiser at Thu Jan 15, 2015 09:22
bpiuser replied at Thu Jan 15, 2015 08:32
@tkaiser: pls. consider the facts first e.g. about the existence of elaborate backup solutions

Can you please point me in the right direction where to find them? I currently only know of Archiware's P5 as a backup/sync solution for NAS systems that provides the necessary features:

  • automatic media management (media rotation, offline media in a round robin fashion)
  • incremental sync/backup
  • versioning
  • and most importantly a user friendly restore GUI where users find what they're searching for

Would love to know an alternative to that

You have to log in before you can reply Login | Sign Up

Points Rules