Thanks a lot for clarifying that macOS doesn't have the ability to identify bays/slots in Thunderbolt enclosures—that makes sense as to why it's not straightforward, and it's another reason for switching to a NAS, where such identification is built-in and user-friendly.
That said, if macOS truly doesn't support identifying bays in Thunderbolt, then how does the PROMISE utility on the Pegasus RAID manage to display which drive is in which slot/bay? See the attached image for reference—it clearly shows locations like Slot1, Slot2, etc. Curious how they pull that off if it's not possible via macOS.
I'm also keen to get a reply to my earlier post about why the NAS with 10GbE Ethernet seems to be faster than the Thunderbolt 4 connection on my OWC drive.
Hi again,
I went ahead and swapped two of the disks to different bays as suggested, but I'm still seeing the same issue—no change there.
That brings me back to a key question: How do I actually identify which of the disks is missing when these ejections happen? You make a big fuss about notifying users about every little thing (which I get, for mission-critical data), yet the software can't even establish or indicate where the missing disk is. I can hardly shut everything down now, pull all the disks out, and check serial numbers one by one—that's an incredibly cumbersome method, especially mid-workflow.
Also, I've included a video here showing how your Blink Disk Light feature works (or doesn't)—it doesn't clearly show any disk as missing, even when there's an issue. So, not a very effective system you've got going there for troubleshooting.
Looking forward to your thoughts on this.
Best,
@steve223
Just a quick follow-up: I went ahead and swapped the hard drives around as suggested, but unfortunately, the same issue cropped up again—no improvement.
After going through that cumbersome method of shutting everything down, pulling out the drives, and checking the serial numbers one by one, I've confirmed that it's the same hard drive that's causing the problems. However, this drive doesn't show any issue markers at all in Disk Utility or DriveDX, and it hasn't even had much extensive run time yet, so it's puzzling why it's acting up like this.
Any ideas on what could be going on here? Would appreciate your insights.
The Promise enclosure is "hardware RAID" the drives must go into fixed locations. If you swap slots, you loser all data. The plus side is the enclosure knows where each disk is. Note: MacOS does not know those individual drives are even connected, it can only see the "LUN" created by the promise management software.
SoftRAID has "Disk Labels", where you can say Slot A, Slot B, etc, as our best equivalent, but these are for naming purposes, it matters not where disks are connected.
I do not know why your disk is taking so long to power up. But that is clearly a faulty mechanism to do this. Power on hours do not necessarily relate to premature failure. We have the "Certify" feature to catch most early failure drives, but I don't think certify would catch this issue. I was hoping DriveDx would show some difference, but since it is not, you can go ahead and uninstall it.
The blink disk lights should show slot indicator, as the blink disks have a regular pattern, but I agree with your criticism that the bright LEDs make it harder to spot the slots.
On performance, I don't have a simple answer. Since your older volume is much more full, that can also impact performance. Its good you are getting decent performance over Gb ethernet however.

