I'm planning on using something like this newegg.ca/Product/Product.aspx?Item=N82E16817576009 when I buy the Odroid HC-2.
Weird combination. The ODROID-HC2 has 2 USB3 ports that are already used (one for Gigabit Ethernet, the other for the JMS578 SATA controller) so all you have left is a slow USB2 port. So the HC2 is a nice device to connect one 3.5" disk directly and maybe attach USB disk(s) for backup purposes.
If you plan to use more than one 3.5" disk you should really choose a better approach (I would immediately buy a HP Microserver but they're pretty inexpensive here in this part of the world). At least I would try to avoid these crappy USB multi disk boxes at all. Please use the search box in the upper right corner, search for eg. 'mediasonic' and educate yourself about the various problems you'll run into (eg. not able to query SMART data of the drives and so on)
The HC-2 is pretty much my one and only option that is 100% headless, inexpensive and small.
Good luck with this style of thinking 
All OMV ARM images work 100% headlessly regardless whether there's a HDMI connector on the board or not, choosing a device with only an USB2 port to attach USB3 disk enclosures when there are loads of other devices available with USB3 or SATA is something I won't comment on and how the search box is working is somewhat self explanatory (if you're in a subforum it reads 'Search This Forum Only' which most probably is not what you want then)
It appears from reviews that the Mediasonic box doesn't support hot swapping/plugging. There's several mentions of that, and one very complete review on Amazon where the reviewer tested this pretty extensively (under Ubuntu, so the behavior should probably be similar to what you'd get with OMV), and it consistently caused the existing drives to unmount and the firmware to reboot whenever a new drive was plugged in. So, not sure that's a good idea while the system is running?
The HC-2 is pretty much my one and only option that is 100% headless, inexpensive and small.
I think there's a few options out there that would work as well, or better, than the HC2 in situations where you need to use an external disk enclosure that connects via USB3. For example, the XU4 (which I believe the HC2 is based on) has two available USB3 connections. This would let you run an external device at USB3 speeds, rather than the much slower USB2. Even if those USB ports are shared with other devices, like the Ethernet for example, a shared USB3 should still be faster than USB2. I don't know if they are shared, but even if they are, its should still be faster.
For example, the XU4 (which I believe the HC2 is based on) has two available USB3 connections. This would let you run an external device at USB3 speeds, rather than the much slower USB2. Even if those USB ports are shared with other devices, like the Ethernet for example, a shared USB3 should still be faster than USB2. I don't know if they are shared, but even if they are, its should still be faster.
XU3, XU4, HC1 and HC2 are fully software compatible. The Exynos 5422 SoC used on all three devices has 2 USB3 ports and one USB2 port. One USB3 port on all these devices is used for a Gigabit Ethernet chip (the much better RTL8153 on XU4/HC1/HC2) and the other connected to an internal USB3 hub on XU3/XU4 (with 2 USB3 receptacles behind -- only those have to share bandwidth) or the JMS578 SATA bridge on HC1/HC2.
So yes, XU4 is the far better option if you plan to use an external USB3 disk enclosure (or ROCK64, Renegade, EspressoBin, Clearfog, all the countless RK3399 devices we'll see soon or a little bit later those based on Allwinner's H6). But all these USB3 multi disk enclosures are utter crap (not just Mediasonic) so better don't use them. They all rely internally in JBOD mode on a SATA PM which slows things down and if you happen to get an outdated firmware these thingies do not even allow you to appropriately access individual disks (affects both reading out SMART values and configuring disk settings via hdparm). And if you configure them to act as RAID it gets even worse (a single point of failure that will prevent you accessing all your data once the controller inside dies and therefore rendering the whole RAID principle useless)
Do NOT buy this crap. If you need multiple disks go with something more suitable for the job.
Do NOT buy this crap. If you need multiple disks go with something more suitable for the job.
Yet, I have 2 of those Mediasonic enclosures running on my Wetek Hub (running with Libreelec on it). One of them has been running for the past 8 years.
XU3, XU4, HC1 and HC2 are fully software compatible. The Exynos 5422 SoC used on all three devices has 2 USB3 ports and one USB2 port. One USB3 port on all these devices is used for a Gigabit Ethernet chip (the much better RTL8153 on XU4/HC1/HC2) and the other connected to an internal USB3 hub on XU3/XU4 (with 2 USB3 receptacles behind -- only those have to share bandwidth) or the JMS578 SATA bridge on HC1/HC2.
So yes, XU4 is the far better option if you plan to use an external USB3 disk enclosure (or ROCK64, Renegade, EspressoBin, Clearfog, all the countless RK3399 devices we'll see soon or a little bit later those based on Allwinner's H6). But all these USB3 multi disk enclosures are utter crap (not just Mediasonic) so better don't use them. They all rely internally in JBOD mode on a SATA PM which slows things down and if you happen to get an outdated firmware these thingies do not even allow you to appropriately access individual disks (affects both reading out SMART values and configuring disk settings via hdparm). And if you configure them to act as RAID it gets even worse (a single point of failure that will prevent you accessing all your data once the controller inside dies and therefore rendering the whole RAID principle useless)
Do NOT buy this crap. If you need multiple disks go with something more suitable for the job.
What is something more suitable for the job? I'm currently looking for a HW RAID Enclosure which can support RAID1 configuration and also pass S.M.A.R.T. Data. I currently have a HW RAID enclosure which implements the JMS561 chipset and I'm unable to get S.M.A.R.T. data returned.
I currently have a HW RAID enclosure which implements the JMS561 chipset and I'm unable to get S.M.A.R.T. data returned.
If you're running with 4.14 then this is most probably the reason: https://forum.odroid.com/viewtopic.php?f=149&t=30125#p216717 (just one of the many 'USB storage' downsides)
Can't help further since I consider such primitive RAID-1 a horribly bad idea...
If you're running with 4.14 then this is most probably the reason: https://forum.odroid.com/viewtopic.php?f=149&t=30125#p216717 (just one of the many 'USB storage' downsides)
Can't help further since I consider such primitive RAID-1 a horribly bad idea...
Let me rephrase the question. With out breaking the bank, what is an ideal setup where one can have near realtime redundancy and be able to monitor the drive's health at the same time? Speed isn't necessarily the utmost concern, but redundancy and the ability to detect issues before there is a drive failure. I've read about your thoughts on Efficient Arm Platforms but haven't read in the forums about RAID enclosures and the like.
Thanks again.
and the ability to detect issues before there is a drive failure
That's not possible with those primitive/anachronistic/stupid RAID-1 modes. They try to write stuff in identical fashion to two drives, when they read they either read from just one drive (mdraid) or different blocks from different drives to increase performance (some 'hardware RAID1' implementations and some other software RAID-1 solutions). In case data is corrupt they are never able to detect this. There is neither data integrity nor data protection involved. Primitive/anachronistic/stupid RAID-1 is always only about availability.
If you want to 'detect issues before there is a drive failure' you need not that primitive/anachronistic/stupid RAID-1 attempt but something that allows for checking data integrity: That's for example a zmirror (ZFS mirror) or the raid1 mode provided by btrfs. Only then and when combined with regular scrubs you get
With primitive/anachronistic/stupid RAID-1 you get 3) only. Why wasting a whole disk for almost nothing?
BTW: Being able to read out SMART values is nice or even mandatory to be able to check for some problems. But it's also not possible to predict a drive dying soon based on SMART readouts or vice versa (SMART data looks ok so the drive is ok too and 'will not fail soon' -- nope, it doesn't work this way).
If you're concerned about data integrity then implement this instead of availability (use modern attempts like those above mentioned filesystems in mirror setups for example). If you're concerned about data protection then implement this instead of availability (some backup concept is needed). It's really that easy as long as RAID is seen as what it is: only the try to increase availability and nothing more.
Alles anzeigenThat's not possible with those primitive/anachronistic/stupid RAID-1 modes. They try to write stuff in identical fashion to two drives, when they read they either read from just one drive (mdraid) or different blocks from different drives to increase performance (some 'hardware RAID1' implementations and some other software RAID-1 solutions). In case data is corrupt they are never able to detect this. There is neither data integrity nor data protection involved. Primitive/anachronistic/stupid RAID-1 is always only about availability.
If you want to 'detect issues before there is a drive failure' you need not that primitive/anachronistic/stupid RAID-1 attempt but something that allows for checking data integrity: That's for example a zmirror (ZFS mirror) or the raid1 mode provided by btrfs. Only then and when combined with regular scrubs you get
- an idea when a drive starts to fail (since data corruption has occured)
- self-healing capabilities since checksums are generated when writing and compared when reading. In case a mismatch occurs both ZFS and btrfs are then able to identify which disk contains bad data, maps this away and replaces it with a good copy from the other disk
- If bad blocks are involved then bad block handling is done too (forcing the disk's internal controller to map these bad blocks away)
With primitive/anachronistic/stupid RAID-1 you get 3) only. Why wasting a whole disk for almost nothing?
BTW: Being able to read out SMART values is nice or even mandatory to be able to check for some problems. But it's also not possible to predict a drive dying soon based on SMART readouts or vice versa (SMART data looks ok so the drive is ok too and 'will not fail soon' -- nope, it doesn't work this way).
If you're concerned about data integrity then implement this instead of availability (use modern attempts like those above mentioned filesystems in mirror setups for example). If you're concerned about data protection then implement this instead of availability (some backup concept is needed). It's really that easy as long as RAID is seen as what it is: only the try to increase availability and nothing more.
I was beginning to wonder how to solve 1 and 2 and even started using a bitrot checking tool to keep a database of checksums. With the idea I would then manually replace the file myself from another duplicate drive stored offsite if/when there was a checksum mismatch. I have read about ZFS and BTRFS but was unable to get my drives formatted it either format through OMV, and on further research I found that ZFS is pretty ram hungry which seems like it might not work for my Pine64. I'll start reading about ZFS Pool and figuring out how to get it to work in OMV. Looks like there's a ZFS Plugin available.
As far as S.M.A.R.T. data, I do realize it's just one tool of many and isn't entirely predictive of a failure. But it's something I'm still trying to understand.
I think as of this point, it's time to scrap the Hardware RAID idea since I'm just having to work around it anyway. It seems best to just remove it from the equation.
As an aside, tkaiser, what would your ARM board setup look like hardware/software wise for storing about 2TB and growing of family photos/videos? Am I silly to think I could get 1, 2, and 3 from above while utilizing an ARM board?
on further research I found that ZFS is pretty ram hungry
Quoting the article: 'Native data compression and deduplication, although the latter is largely handled in RAM and is memory hungry' --> don't use dedup and you're done. Almost everywhere on the Internet people copy&paste 'ZFS is RAM hungry' while they should say 'ZFS dedup is RAM hungry'. The always quoted formula 'per TB of data on disk you need 1 GB of DRAM' is pure BS if it's about ZFS unfortunately.
With low amounts of memory you need to adjust some parameters though and since a lot of people don't want to understand these tunables projects relying solely on ZFS (e.g. FreeNAS) end up with recommendations to use huge amounts of RAM just to stop the same issues popping up in their support forum over and over again.
Unfortunately ZFS with OMV on ARM is not that easy (plugin only available for amd64 architecture, issues with Stretch) so if you're using a pretty recent kernel version I would prefer btrfs on Pine64 if you're after data integrity. If JMS561 devices can be configured to operate in JBOD instead of their RAID modes then everything is fine and you could use such a thing. But beware that performance on Pine64 will be pretty low since then a single USB2 port will bottleneck your storage.
Personally I don't do RAID at home since useless (I prefer to waste another disk for backups instead of availability). And those cheap ARM thingies are great since you can put one in another room, flat or even city and send the backups to it so that you are protected from a lot of more data loss causes than with a disk in the same enclosure wasted for availability/RAID. On the main location only Marvell boards (EspressoBin and Clearfog) with btrfs and tons of snapshots are used, in remote locations (friends, parents) where I send snapshots/backups to ultra cheap Allwinner H3 and H5 boards do the job...
Tkaiser, I just ordered an EspressoBin and a 4 Port SATA III 6G Mini PCIE Mini PCI-e Marvel 88SE9215 Controller Card based on your advice. Thank you very much!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
