[Sticky] SoftRAID driver not loading at startup in Big Sur - workaround in SoftRAID 6.1 beta
We are still in beta with 6.1.
It was not trivial to add this, as there are cases where this does not work. Some kind of timing issue. But we have it in.
Apple still has not fixed this. In the meantime, I have dicovered this can affect Parallels, Roxio and other drivers.
@softraid-support yeah well nothing in sw dev is ever as easy as it should be eh? always timing and race conditions when dealing with os shell scripts but eventually you learn how to handle them correctly. parallels was causing all kind of issues for me running my vm from external raid. it seems to corrupt the vm if the vm is not paused or stopped and the computer goes to sleep. major pain in the ass to recover from. sometimes you get lucky and it will restart after wake from sleep and sometimes the vm is just totally jacked and you better hope you had a backup.
You will be at least happy to know that in our testing, we could find no ill effects from reloading the driver after startup, so with Big Sur, we will just do this automatically. No need for a preference file.
Now if we can just figure out how to stop the disk reordering, or find a solution that works without overly complicating or affecting performance of the SoftRAID driver.....
@softraid-support exactly, there is no need for a preference but probably best to only do it for unmounted drives. the sleep reordering is a critical issue that really needs a fix duct tape or not. It’s corrupted so many vms for me. Very painful
Is the sleep /disk renumbering causing data corruption in your VM's?
Is that from them shutting down incorrectly?
if they are on SoftRAID volumes, the driver locks the volume as soon as this state is detected after waking, so there can be no IO to the disks. Maybe it is because they are in an "inconsistent state" as they are not shut down, and locking the volume, causes them to be inconsistent at shutdown?
Maybe this is a way we can get some movement on this. thanks
@softraid-support correct, i believe whatever data had not or needs to be written to the vm files gets purged somehow due to the lock and it has a high possibility of the vm no longer working. sometimes parallels is able to recover and sometimes not. whenever i would return to my sleeping computer and wake it and see the string of softraid error dialogs i knew i had accidentally left the vm running before leaving and there was a 50% chance i would have to start all over. it was a hard lesson to learn to eventually move all my vms off the external raid to not lose all my work. since then there were no longer any vm corruption issues accessing them from internal storage. i have since retired and no longer use parallels or vms much but yeah this was a serious major issue that really hurt.
Understand. I guess the only practical solution at this point is unmount volumes before sleep.
We discussed this in an engineering meeting again and the main problem with trying to work around this is introducing bugs or data corruption, where we cannot tell where it is coming from, particularly macOS or our driver. At least now, we have put a halt to data corruption caused by this issue.
(imagine if the SoftRAID driver wrote out data to the wrong disks, that is the real problem with this issue, and why we had to put in such an extreme measure)
When I was running BigSur 11.5.2 the softraid kext and ZFS kext did not load on startup and had to manually loaded with terminal commands. I just updated to Big Sur 11.6. Both kexts are now loading normally at startup.
This is not a driver issue, it is a volume directory problem. It appears to me some process erased the volume header.
How did this happen? When was the last time your volume mounted?
Do you have access to Disk Warrior (and a computer with Catalina or older on it?)
Sorry, I mean is the data backed up elsewhere? This may be difficult to repair the volume, it may need data recovery. There is no information at all in the volume header. (which tells macOS where the volume starts and where the directory is located)