RAID5 on raspberry with USB drives

    • OMV 2.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • RAID5 on raspberry with USB drives

      Hello,

      I'm running OMV 2.0.15 on a raspberry pi with 3 harddisks in 4-bay sata harddisk-to-usb box. (probox with sata usb hub only)
      The harddisks are visible as /dev/sda - c

      The issue is now that obviously at system start up the raspberry (1GB version) is faster than the harddisks are starting up and getting visible as devices, so md0 will not get started at boot time.
      As this fails I'm doing a mdadm --assemble md0 to get the raid up and running (only after all 3 devices are visible). Now because of that startup of md0 failed at boot time, the array will not be created as md0, but md127 on top of everything...

      So my questions are:
      - What is the official way for the raspberry image of omv to get usb drives started within a raid? Producing an image for raspberry a connection of an USB storage device was probably not so unexpected.
      - Do I really need to run a bash-script after start checking if all devices are visible and the reassmble the raid or is there any other consideration of that part of OMV already?

      What I specifically don't like about that, is that configuration is partly in the web-gui, partly in bash script to get the raid configuration alive again, after system reboot...

      Any thoughts about this?

      thanks,
      best regards
      Tjareson
    • While expected, there is no "official" way to get the image to work with a usb array. I don't have three usb hard drives to test with. Three flash drives worked fine if I remember correctly. USB hard drives also have different startup times across manufacturers. So, from what I can tell, you will either have to use a startup script or stop using mdadm raid. You could use a unionfilesystem or snapraid or something else. This isn't an OMV issue. Not sure what else to tell you.
      omv 4.1.13 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • I've implemented a script in /etc/rc.local now, which is waiting until all 4 usb drives are up and then assemble the Raid 5 and mount everything (there is one remaining disk, not part of RAID5 in my case, which also wouldn't get mounted by OMV, as not available when fstab gets applied)

      It is not so much about if it is an "OMV-issue", it is just trying to find a solution solely based on OMV without extra hacks. Making use of old harddisks with a cheap raspberry pi is in my opinion a very feasible setup. So it would be nice if OMV somehow could handle it without extra scripts, which needs to be adjusted, whenever certain changes are done in the web-gui of OMV. Not sure what I could possibly contribute to support this?

      Anyway, here is the script part for /etc/rc.local for the time being, just in case anyone else is facing similar problems. It is based on the script I found here: webdiary.com/2011/02/06/wait-for-usb/ I've adjusted it for four drives and changed syntax for sh instead of bash.

      Source Code

      1. ​usbdrive1="/dev/sda"
      2. usbdrive2="/dev/sdb"
      3. usbdrive3="/dev/sdc"
      4. usbdrive4="/dev/sdd"
      5. # Max time to wait (in seconds)
      6. maxwait=180
      7. case "$1" in
      8. start)
      9. echo "Waiting for USB disk drive $usbdrive"
      10. for i in $(seq 0 $maxwait)
      11. do
      12. [ -b $usbdrive1 ] && [ -b $usbdrive2 ] && [ -b $usbdrive3 ] && [ -b $usbdrive4 ] && exit 0
      13. echo -n "."
      14. sleep 1
      15. done
      16. exit 1
      17. ;;
      18. stop)
      19. ;;
      20. esac
      21. sleep 3
      22. /sbin/mdadm --assemble /dev/md0
      23. sleep 3
      24. /bin/mount -a
      Display All


      It needs to be inserted into /etc/rc.local before the exit 0 statement, which is usually at the end.

      best regards
      Tjareson
    • Glad you have a something that works. This is tough to fix at the OMV level because it isn't common. While there are plenty of people using an RPi as a NAS, most aren't using mdadm raid. They are either letting the usb enclosure do the raid work or just have disks connected.

      I suppose a plugin could be created that enables/disables a script that loops through all drives found in mdadm arrays and then assembles/mounts them (just like your script). Unfortunately I don't have much time.
      omv 4.1.13 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • Is there any update on this topic?

      I have a similar setup on an Odroid XU4 with two USB3 drives in RAID1 mode. After every reboot I have rebuild the RAID. Luckily, this is only a test system right now and no data got lost so far.

      I modified Tjareson instructions to my setup but no luck so far.

      Thanks,
      Martin
    • kuschi wrote:

      I have a similar setup on an Odroid XU4 with two USB3 drives in RAID1 mode
      Really bad idea. Almost all those concerns apply to your XU4 situation too: RAID with Raspberry Pi

      USB RAID especially with all drives behind an USB hub is something you want to avoid (RAID in general with such an unreliable SBC setup -- it's only wasting disks and energy)
    • Hi,

      Thank you for the prompt response. I now know better that the XU4 is not the perfect hardware for OMV, but is a fairly inexpensive and convenient way to test and get to know better about OMV and all its possibilities. At least I now know better all OMV's limitations, for hardware and software.

      Thanks,
      Martin
    • kuschi wrote:

      I now know better that the XU4 is not the perfect hardware for OMV
      No, this is not related to OMV at all. XU4 is just not the perfect hardware to attach USB3 storage to (see my signature for more explanations) while in fact OMV tries to mitigate this by some tweaks (detection of problematic USB-to-SATA bridges and applying 'fixes' for those).

      And in my personal opinion mdraid-1 is simply not worth a look (any more) since providing almost no protection against usual hassles (especially on such SBC where the disk connections are best described as 'utterly unreliable').
    • kuschi wrote:

      What would be your recommendation to attach storage to this kind of SBC? Other than the internal SD card or eMMC module?
      None since unreliable. It's just the wrong SBC for the use case. Hardkernel learned their lesson and they came up with ODROID HC1 and HC2 which successfully eliminate most of the XU4 USB storage hassles.

      SBC with native SATA exist as well as those with PCIe where you can attach a SATA controller to.
    • kuschi wrote:

      I have successfully configured
      Sorry for being not clear enough. I'm not talking about OMV or anything wrt software/settings at all. Just that some SBC are simply not sufficient to do RAID with them (or attach any storage at all). If the whole setup is unreliable it's pointless to play RAID.

      It's about USB hubs between host and disks, about reliability of cable connections (horrible with USB3-A), about underpowering and about issues with USB-to-SATA bridges in disk enclosures. You can't fix anything here in software. It's a matter of (replacing the) hardware to get reliable storage operation which is most basic requirement for RAID to be able to do its job (only providing availability -- not related to data protection at all)