Looks like a great way to build a 2nd Rockstor server for backup at a much lower cost than my main NAS.
Any experience or thoughts welcome this will be my first Pi project.
That looks very interesting. Although Iāve not done a Pi4 install with that HAT, I have used the base Pi4 board successfully before, using USB3 connectivity to a HDD hub.
This would be an interesting little project.
Thanks @GeoffA Iām really trying to put together a nice tight package so a single case design like that one, or this one
with 4 2.5" drives is my goal, but Iām not sure if Iām going to have unsolvable compatibility issues. Both of these vendors use OMV as their NAS solution, installed from the Pi CLI. Not sure thatās a good corollary for what I can expect with the rockstor image.
The Raspberry Pi4 part should work just nice with Rockstor as it is a Pi4 after allā¦ What is always the source of worry are all the different bits that these cases have built-in. In particular, it is important to know how the SATA controller(s) surface the devices to the system as Rockstor (among others) needs to have a unique serial number for each device so that it can reliably keep track of it. Luckily in this case, their docs seem rather good on this as they do talk about it. Unfortunately, however, they do state that the controller used does not provide a unique serial number for each drive as required:
JMicron controllers incorrectly report identical serial numbers and other data which confuses various systems.
They do list a workaround using udev rules, which is something that Rockstor also does. We might be able to include something like that in Rockstor but I personally am not the reference on the matter; @phillxnet should be able to provide some input on that. It seems like a really nice case so it could be nice to see if Rockstor can work nicely without the user having to do anything special on it first.
The Argon EON Pi case also looks really niceā¦ I wonder if it reports unique serial numbers for drives or if it would require a custom udev rule as well.
Having looked at this a little further, this āHATā is nothing more than a USB drive hub using the GPIO for some OLED display and PWM fan stuff, as well as some power/reset stuff. It uses both the USB3.0 sockets on the Pi4 board for accessing the drives. The issue of unique drive serial numbers will raise its ugly head and will need some udev to sort out.
However the all-in-one case approach does look pretty, I must say.
Apart from the additional udev workaround needed, I reckon this would work fine with Rockstor on the Pi4 out of the box: its no different to attaching a separate USB drive hub to one of the Pi4 USB3 sockets, which I have successfully done before. Although both are used in this case.
EDIT: I forgot to add that USB HDD hubs can have issues passing SMART info as well. FYI.
Thanks @Flox and @GeoffA for the help. I was doing some more reading and it looks like they use python to drive their OLED. So if I understand your inputs and what Iāve read on the radxa site, Iād install Rockstor on the Pi SD card. Start the system, and fix udev, the write ups look pretty straight forward. Then download and install the radxa script to enable the OLED. Sound about right? Thanks for all your help.
Radxaās sata software [curl -sL https://rock.sh/get-rockpi-sata | sudo -E bash -] appears to only support Ubuntu and the pi o/s so it would seem only omv is possible until some bright person can fix it to support Rockstor - which would be great!
Thanks for pointing that out, @bwc!
This script seems to āsimplyā install some dependencies through the distro package manager as well as pip; if these packages are also available in openSUSEās repos, then it might be doable.
The feasibility and appropriateness for Rockstor of the udev rules listed in their wiki would need to be confirmed first, though, as I would believe this would decide whether Rockstor can have proper device management with this hat.
I agree it would be great, though, as it seems like a nice case/package.
A bit of digging around in GitHub I came across this: https://github.com/nolltre/rockpi_sata which seems to suggest that the sata interfaces are controlled via some GPIO pinsā¦
Loads of great info in this thread. But my preference would be for hardware that requires less trickery. Also not convinced that udev tweak will work for us regarding unique serials. Plus using each USB 3.0 for no just one but two sata ports is not āniceā. the USB bus is notorious for resets. If 2 sata ports are hanging off one port both sata ports will also die with them. Iām not sure of the port allocation re the Pi4ās 3.0 USB ports but if they also share a bus then all drives may end up being reset.
My preference would be for a system that uses a Pi4 compute module and uses itās PCI bus to drive regular SATA implementations directly. That way one avoids the USB bus/busses completely. They are generally not recommended for storage. Especially robust storage.
But yes, these look nice bits of kit.
@bwc Nice find there re the more generic hardware initialisation project. Also note that they mention dependencies on custom kernel modules. That is another worry, and in this case it is regarding the fan I believe. Not sure what else form an initial quick read.
Iām super interested myself in finding a nice Pi4 NAS hardware arrangement but from a technical point of view it is generally ill advised to use USB for anything that needs robustness. Itās a bus that has been plagued by unreliability for quite some time now. Also not favoured (over time) on the btrfs mailing list from memory. Hence the compute module approach as then the PCI bus option becomes possible: avoiding the USB all-together. This also in-turn frees up the USB 3.0 for the non raid single system disk and a fast dongle for the Rockstor system. I got the impression that there were boot difficulties from the drives connected to that hat. Not certain thought. And the sdcard interface on the Pi4 is a tad slow for our still on the heavy side system disk. But we should speed up some as we move to Python 3. But will likely always be a little on the heavy side.
Hope that helps.
But as always; interested in folks feedback on experimentation. And we do have a fully customisation DIY installer option, with pull requests welcome. But given the potential for interference we may only be able to add stuff remarked out. Or not enabled by default. And we have to watch for license concerns for any custom code we may have to pull in to drive stuff.
@phillxnet Thanks for the feedback, I share your USB concerns I didnāt think that was a great method, Iād much prefer the PCI bus option, so the hunt continues.
Agree PCI bus is much preferred - YouTuber Jeff Geerling (https://www.youtube.com/c/JeffGeerling) has done a lot in this area - well worth looking at his experiments.
As soon as the compute module becomes more readily available I will be putting one on my shopping list but in the meantime, Iām persisting with the Radxa SATA HAT and have successfully installed Ubuntu Server ver 20.04 /Samba with two 2tb disks - one SSD and a rusty spinner and am copying files furiously as I typeā¦ no udev tweaking required! It is slow (Mac Finder reports 7 hours to copy 264gb but seems perfectly suitable as a backup boxā¦
The Axzez board looks very interesting and at only $120 worth a punt although not sure if they ship to where I live (UK). The Wiretrustee board isnāt available right now. The only problem (hardware-wise) is of course sourcing a CM4 ā¦
As alternative to the Radxa had you might want to have a look at NanoPi. They have a 4x SATA hat for their M4V2 Pi-board that uses PCI-e to Sata instead of USB:
I was considering this approach as well, but in the end went for embedded motherboards because of delivery issues with everything Pi-related or Pi-like due to shortages.
Another option, although with āonlyā 2 Sata connections, might be the ODROID-HC4. I suppose you could transfer the mainboard to another enclosure if you donāt like the exposed drives.