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. 

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.

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

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.

And, MacOS does not have the ability to identify a bay/slot in Thunderbolt. That is why we have "disk labels" as a feature. MacOS randomly assigns disk numbers when you connect an enclosure. 

Thanks for the detailed response and for clarifying your perspective—it's helpful to understand the philosophy behind SoftRAID's design and alerting system, even if we don't agree on everything.

On the drive identification point: I don't think adding a simple way to show which bay a drive is in would make your software "bloatware" at all. Actually, you do not keep to the "Keep It Simple" ethos, because "Keep It Simple" would be if I don't have to take out drives or go through elaborate blinking light watching operations to figure out in which bay the drive is. Noting the serial numbers means I have to physically take each drive out to check, which is a hassle. And the lights don't work reliably if there's any read or write activity going on. Identifying which bay has an issue is basic functionality in my book—my NAS certainly does it, and the Promise RAID does it too. It would make troubleshooting so much easier without violating any "keep it simple" ethos.

Regarding your prostate exam analogy: Fair point, but let's flip it for a comparison—if I go to one doctor who tells me there's an abnormality that needs constant monitoring and alerts, but I still live to a ripe old age of 90 without it ever causing a real problem, then it doesn't help me at all compared to the other doctor who said there's no abnormality and let me go about my life worry-free. I think you know what I mean—as long as the end result is the same (no catastrophic failure), I'd rather not hear about every minor blip and potential issue. Constant alerts can be more stressful than helpful if they're not actionable or critical!

That said, I appreciate the suggestion on the VPN bug workaround—I'll give the uninstall/reinstall a try and see if that sticks the "don't show again" preference.

As for the faulty drive theory, I will pop the drives around tomorrow (swap them to different bays) and we'll see how it goes. If the issue follows the drive, that would confirm it's the HDD; if it stays with the bay, then it's the enclosure. Either way, I'll report back if anything interesting comes up.

Based on your latest observations, I am 100% sure you have a faulty hard drive. However, you still need to try swapping it with another bay to ensure that it is the drive, not the bay.
This is becoming a more and more serious issue.

When sleep/thunderbolt are an issue, it is ALWAYS 100% of devices in an enclosure ejecting, never just one. So that is a red herring as far as you're issue is concerned.

In. order for SoftRAID to know which drive is "missing", it has to keep a table of drives in every volume. it violates the "keep it simple" coding philosophy that has kept SoftRAID efficient, non bloated and efficient, for a product that is 30 years old. Go look at all the "old" apps you use. They are bloatware. SoftRAID is not.

You can tell which is missing by noting the serial numbers and seeing which is missing. Also using Blink Disk Light to see which drive is not blinking. Then you ID'd the missing drive by elimination.

I am sorry about the VPN bug. You can try 'uninstall" SoftRAID, restart, then checking the do not show again box. See if that helps.

For being alerted about sleep issues, here is a question: 

if you go to the doctor every year and he never does a prostate test, then you go to a different one, and you have a problem, did you only have a problem when the new doctor reported it? Or, was it an undiagnosed issue all along?
SoftRAID is reporting these ejects, because we think it is serious. MacOS ignores this as much as possible. Which would you rather have?

a simple proof would be (we tested this), is take an enclosure/cable/mac combination that ejects during sleep. Convert them to Apple format drives (volumes). the messages magically go away. Is that a good thing that you do not know of this issue?

On another hand, the waking from sleep issue during hibernation happens regardless of driver or even with a raw unformatted disk, about every 45 minutes, drives spin up for several minutes. But, you likely only notice this with multi-drive enclosures. (a single drive enclosure is less likely to be audible.) Does this mean the wake during hibernate only happens in OWC enclosures? 

I am being a bit sarcastic, but we are living in the real world, with real bugs, some which we can deal with, some we cannot.

But the SoftRAID driver motto is effectively, "tell the user about every issue, do not ignore any". That means we are a strong messenger for issues, as for mission critical data, users should know about all issues, whether "minor", infrequent, or what. Let them decide whether to ignore alerts, don't hide/ignore issues from users.

Second, it seems you're failing to understand that while you are paid to provide support and troubleshoot for OWC, I am not. I'm a customer who's already spent a ton of time on this, and I'm currently in the process of migrating everything to my new QNAP NAS, so that's where my focus is right now. If the OWC unit turns out to be faulty, it'll just go in the bin because it's older than three years and out of warranty—it's simply not my top priority to invest more hours into troubleshooting it at this point.

I have downloaded DriveDX as you suggested. Interestingly, one of the disks doesn't show up in DriveDX at all intially, yet SoftRAID after a rebuild shows it as fine. As I said before, these issues exist on both OWC enclosures when they go to sleep. So we seem to have two issues here: One is that OWC doesn't deal well with the Mac waking up from sleep (ejections happen even when "put hard drives to sleep" is disabled). And then the second issue is only pertaining to one of the OWC enclosures, where that one hard drive disappears, reappears, and then needs to be rebuilt after every restart. Indeed, that could well be a hard drive issue—I'm currently talking to the vendor (Toshiba) to get a replacement under warranty. But it doesn't solve the underlying problem that you pretty much can't let your computer go to sleep with the OWC enclosures.

Again after more trouble shooting and yet another restart,the same OWC RAIDs came up with a hard drive missing. So I ejected the RAID, switched it off, restarted the RAID. Then the hard drive showed up as missing briefly, then it showed up as there, but the RAID was out of sync. It rebuilt the sync of the RAID, and now it shows up fine. I also attached the four drive reports from DriveDX, which show that all four drives seem to be fine, including the drive which constantly goes missing and then reappears. So it's pretty hard to blame it on the drive then, as DriveDX, DiskUtility and SoftRaid also all mark all drives as fine.

After every restart, SoftRAID warns me of no VPN being installed. And every time I click "don't show that warning again," as I have none of the helpers which supposedly cause the issues installed, yet SoftRAID every time shows up that message again. Not a big deal, but maybe it shows a lack of attention to detail.

In regards to a clean install, this is a fairly new Mac Studio Ultra that already had a clean install when I set it up—not migrated from anywhere, but everything from scratch. Doing another clean install on a second volume and testing that would be hours of work, so that's not something I'd consider as a first (or even second) line of troubleshooting—it's just too disruptive.

To give more details on the behavior: That disk in question was showing perfectly fine. Then on the next restart, it doesn't show up at all, triggering the rebuild. Then on the following restart, it shows up again but needs to be rebuilt (the array turns red), and after that's done, it shows up as fine again. It's intermittent like that, which makes me question if it's purely a drive failure.

Finally, I'm wondering—with such sophisticated software, why couldn't SoftRAID show me easily which drive bay we're talking about? That can't be that hard to implement—showing it as part of the drive information in which bay it's in would certainly make troubleshooting a lot easier for users.

Best,
@steve223

You have a fault in your system, which I am trying to help you diagnose. Its not our generic hardware that is the problem, its your specific hardware. There is clearly a hardware issue and you keep expecting SoftRAID (i.e software or a driver) to fix it.
You have not tried a clean install (second system).
You have not tried moving the disk that is missing to a different slot.

I even suggested trying a third party app (DriveDx) to help you get more information on the potentially failing drive

Its hard to assist meaningfully when you expect a magic answer!

You either need a new disk, or a new enclosure. There is no other "fix". Or live with it until the storage system fails on you.

That said, I don't get paid to do huge amounts of troubleshooting, and I simply don't have the time for things like installing and reinstalling macOS on new volumes, setting up trial modes, or running extra apps like DriveDx. I've purchased hardware products that advertise reliable RAID performance and plug-and-play compatibility with Macs, and I just expect them to work that way without all this extra effort on my end.

Anyway, I received my QNAP NAS today (the TS-873A), and interestingly, connected via 10GbE Ethernet and still synchronizing, it's already faster than the OWC ThunderBay via Thunderbolt 4—which is not what I expected at all. And given that I'm using Ethernet, I shouldn't have any of these ejection or rebuild issues moving forward.

For reference, my QNAP TS-873A with 5 HDDs in RAID 5 is showing write speeds of 447.8 MB/s and read speeds of 513.7 MB/s—and that's without an NVMe cache installed (which is coming next week), while the unit is still rebuilding, and with only 8GB of RAM (more is on the way too). In comparison, the OWC ThunderBay with RAID 5 gets about 430 MB/s write and 522 MB/s read. While I sure would prefer the plug-and-play simplicity of the OWC units, the amount of grief and time they've cost me so far is actually crazy if I think about it.

In my opinion, you shouldn't sell these products if they don't really work reliably, no matter who is at fault here—whether it's Apple, SoftRAID, or something else. It's been a disappointing experience overall.