I just installed Rockstor 4.0.8 built on Leap 15.3 onto an HP DL380 G9 and paid up on a subscription. I have three volumes presented via the SmartArray controller - 146GB boot/system volume, a 50TB data volume on spinning disk, and a 3TB SSD volume. The big one is intended to be presented for bulk data, and the SSD would be a data store for virtualization hosts.
Rockstor apparently doesn’t like the non-system volumes.
I’ve attached a screenshot, but it basically says the serial numbers are invalid and I can’t really do anything with the disks. But I thought the OS was the one that generated those serial numbers when it first scans the bus.
I also get the following traceback when I attempt to view the disks by clicking the disk ID:
Traceback (most recent call last):
File "/opt/rockstor/src/rockstor/storageadmin/views/disk_smart.py", line 58, in _validate_disk
return Disk.objects.get(id=did)
File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/manager.py", line 127, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/query.py", line 334, in get
self.model._meta.object_name
DoesNotExist: Disk matching query does not exist.
No, they are ‘read’ by the os, udev I believe, from the hardware itself. I.e. a ‘real’ disk drive will have a hardware serial associated with it. These serial number then enable udev to create by-id names that Rockstor then uses.
From what I see, guessing a little here from your description, you have used the build in raid controller to generate virtual ‘disks’. This is not advised and will (looks to have done) throw out the udev. It’s not advisable to have hardware raid underneath software raid. Let Rockstor have access to the disks directly and have it do the partitioning up via shares. That way it can track the actual disks and user the ‘raw’ and as a consequence track the good copy of a data via the checksums employed. Hardware raid, especially in consumer units, is unable to know which ‘copy’ of a block is the good one. Btrfs can however assertain this in many cases.
Good to see the v4 installed OK on your HP DL380 G9. Just got to get the disk pass-through JBOD arrangement sorted in the hardware and then all raid stuff can be handled by Rockstor. Assuming it (read udev) can read the serial numbers.
So in short; present / pass-through / JBOD the disk whole as individual members to the Rockstor system and you all should be ok. Fingers crossed and let us know how this goes.
I wiped my installation and changed the controller to HBA mode, giving the OS direct access to the disks to see how that goes. But it did bring up a question.
Now that the OS can see all 24 disks in the system individually, I didn’t see any option to add protection to the system disk during installation. Going the normal route with the hardware controller active, the system disk would be a RAID 1 logical disk with a hot spare. Does adding system disk protection come later in the install process?
No, we, and upstream to an extent, do not yet manage btrfs raid on the system disk. It’s a shame but there is some work to be done in grub and systemd I believe. We should inherrit this from openSUSE once that is accomplished but we then have to migrate our system disk management (suspect) to our new shiny data disk management. That way we end up simplifying our code and gaining a bunch of flexibility. Before we had btrfs in partition (not recommended) capability we had to ‘special’ case our system disk so it would fit into the rest of our btrfs disk management. Now we have that sorted, within defined limites, we need to transition that work to the system disk. It’s a job that will need some very careful attention. I’m looking forward to it actually as we get to simplify our stuff and throw out some old hacks but all in good time.
Only once we have the above work in place. Best in all cases to not store critical data on the system pool for he time being.
Hope that answers your question.
So am I to understand that you are now up-and-running in Host Bus Adapter mode and all disks are showing up as intended. If so that good good to know.
Cheers. Hopefully in HBA mode you will also now get proper S.M.A.R.T exposure to the OS, another issue with some hardware raid arrangements.
Keep us posted as to how you config things. And avoid the parity raids of 5/6 for now at least.
With HP’s SmartArray controllers, S.M.A.R.T. is still not supported, even in HBA mode.
What would be the issue with RAID5/6? Is it an issue in BTRFS? I need about 40-50TB of usable storage, and using RAID10 is going to make the storage relatively expensive compared to parity-based RAID.
On a personal note, I used RAID5/6 for a few years (2016-19 when btrfs was less stable than today on a 4x4TB setup), without any issues, but I was also not too concerned about data loss. Only with my last disk replacements a couple of years ago did I switch to RAID10. But, it probably worked for me, because I didn’t have major read/write activities going on for extended periods of time (and fortunately, never experienced an unclean shutdown (power loss, network connectivity loss, etc.) when I was transferring large amounts of data).
As usual, if you have good backups, and depending on your use case, it might not be an issue, but it certainly would be safer to use RAID10 instead.
