SoftRAID Volume Locked error
@softraid-support have never given any read and write problem nor disconnected that’s good enough for me. It seems like that with Thunderbolt 4 the software raid approach you are using is not longer a reliable way to provide a RAID array. Hope you come up with something better as I like your price range and overall quality but the issues render them unless to me hence I sold 3 of my OWC raids and bought Pegasus and Drobos.
I took notice of your suggestion and tested my Thunderbolt connections - all passed.
Like steve 223 and others, I find SoftRAID to be a good concept and product with good support. That is why we want this issue fixed and fixed soon. I am reasonably certain that this issue only started when I upgraded to the most recent version of SoftRAID and that's why I favour the idea that it is a software problem.
Looking through all the posts, Apple has been blamed and Thunderbolt has been blamed and a couple of other things have been blamed. But blame is never attributed to the software running SoftRAID nor to the OWC enclosures yet they seem to be the common denominator.
Has anybody with this problem been using SoftRAID with a non-OWC enclosure - just to eliminate the OWC enclosures as the source of this issue?
In terms of problem solving, SoftRAID is now reaching the point of needing to call in external software auditors to identify the cause of this problem because it is not being solved internally. There's plenty of software development houses that take this sort of action. Cheaper for the company and better for the clients in the long run.
We have been focused on making the highest quality enclosures for years now. I think OWC enclosures are among the best built.
I try here to explain the root cause of the volume locking and disk ejects, it is a difficult subject to describe. In the simplest case of a computer and enclosure, there are 4 thunderbolt chips communicating with each on the bus. Any one of them resetting will eject the disks. If this happens during sleep, then the volume lock message will be the result. See my next post for more info.
Maybe this will help you with this. the SoftRAID disk driver is essentially a pass thru driver. All actual disk activity is performed by macOS's disktool.
When this first started happening, we reported this to Apple with no results. Finally, we took a full working system, with drives to show the problem. The main clue was a System log entry showing the bus was resetting. A fix was implemented in macOS 10.12 for this. The fix removed a PCI bus reset that was happening. This reduced the ejects by about 90%. (perhaps more)
There has not been any further fixes to Thunderbolt as far as I am aware of. The difference with the current issue, is there are no clues in the System log with the current issues.
Another example is Fibre-channel cables, which should be the most robust of all Thunderbolt cables. Turns out they are also susceptible to the disk ejects and worse, after about two years, start to fail with frequent disk ejects.
And to your question of whether we see this in other enclosures/drives, etc, yes. all the time, although since OWC Thunderbays are the vast majority of disk uses with SoftRAID, we are going to see far more examples with OWC enclosures. But yes, we see this with all other enclosures.
One more example: I mentioned in the previous post a single enclosure setup has 4 separate thunderbolt chips. Add another enclsoure, that adds 4 more.
I did a test once with trying to get 100 drives running on a Mac, in 20 separate enclosures. Impossible, the disks were constantly randomly disappearing/ejecting. After about 4 or 5, enclosures, the frequency of ejects increases dramatically.
Also, adding thunderbolt monitors, docks, and other Thunderbolt devices also increase the frequency of disk ejects.
Its a very frustrating issue. The thunderbolt bus is a multi-Gigahertz frequency of communication. It does not take much to have an interruption.
The sleep issue is similar, but is more likely caused by the chips resetting either during sleep or at time of sleep. If the disks ever power cycle during sleep, you will 100% get the disks re-ordering.
Hope this helps explain this issue.
I would much rather this be our bug, so we could fix it! In my opinion it is a design issue. It was a very cool decision to support hot swapping by instantly powering off devices when a cable is pulled. But no one thought about the potential consequences.
@softraid-support yes as I said before good quality enclosures at the right price and I have been Using Soft Raid on and off for ages but given the technical issues with Thunderbolt 4 I opted to pay nearly double and switched back to Promis enclosures (which works closely with Apple) and all issues disappear. In the end, as a customer, I don't care who or what is the cause of the issue I just know I spend nearly 4k Australian $ on OWC enclosures and had to sell them again after a few months with a good loss because they could not work in a production environment.
I know changed to the Promise R4 Thunderbolt 4 and Drobo 8D Thunderbolt 4 and have not had a single problem in 6 months, I can even let the machine run overnight again without coming in the morning to dozens of disk disconnection issues.
Maybe it's time for OWC to ditch SoftRaid and work on a hardware raid solution as current technology does not seem to work with SoftRaid devices reliably anymore.
Moving my Thunderbay to the left side of the computer and the 5k display to the right did not change anything. The computer still reboots consistently. At this point the Thunderbay is unusable because it makes my entire computer unusable...
Adding most recent support file in hopes it assists in identifying the issue.
I am not sure I understand this one.
Are you getting "panics", or only dialog boxes that the volume is locked and told to restart? (there are many volume locking messages in the log)
If panics/crashes, can you save me a panic log (after restart, report to Apple, more details and save the text into a text edit file)
If the problem is only the locking, what if you change the sleep delay from 10 minutes to never?
Is it ever locking while actively working, or just when the screen saver kicks in?
I get panics all the time. Typically, they happen every couple of hours but of course since you asked for the problem report my computer stayed up a couple of days this time before crashing, but it did ultimately panic again. FWIW - I usually send the report to Apple in hopes that something will get fixed...
Here is a copy of the Problem Details.
Here is the SoftRAID Support file you requested.
Can you check the cables, move to different connectors, etc. There are so many disconnect related issues being reported, it fills up the SoftRAID log with nothing but.
This appears to be the thunderbolt bus resetting constantly, I can kind of see how it would be also creating panics. What if you swap the cable with the Monitor, just as a try?
Also, try with the monitor connected on the opposite end of the computer to the drives.
If you ran for a while without the monitor, do you still get the ejects?
@softraid-support I have a OWC Mercury Elite AL that has been running continuously for just over ten years and never an issue. It has probably be turned off for less than an hour during that time.
However, I have owned OWC enclosures for some time and in that time I have had two 4 bay enclosures failed. One kept scrambling the drives and the other had an intermitment power supply issue. That's two bad ones out of nine enclosures. So I can believe this issue might be related to OWC enclosures. That's why I wanted to know if this volume locked error is happening on non-OWC enclosures. OWC needs to have a really good look at its enclosures and do some really good testing.
It does happen on other enclosures. As someone who does support for SoftRAID for all users, OWC and non OWC users, I can promise it happens on other brands. Same with the disk ejecting. The volume locking only is evident when those other enclosures are either JBOD mode, however, or in SoftRAID format, where the user is alerted to the problem.