SoftRAID 6.2.1 Better Than Ever

With any software product which has been shipping for a long time, it is important every so often to stop working on new features and instead spend time fixing difficult bugs and performing extensive testing. SoftRAID has been shipping since 2003 and during the past 2 decades, we have periodically switched gears to focus on fixing these difficult bugs. SoftRAID 6.2.1 is the result of one of these efforts. It has been four months of research, testing, and coding to fix these problems.

The work on SoftRAID 6.2.1 started last summer and involved many months of testing, both at our main development location in California and with our hardware team in Taipei. Our testers were focused on duplicating the difficult bugs, some of which only a few of our users had reported. We also had help from Apple engineers understanding some of the undocumented aspects of macOS.

Bugs fixed in this version

The following is a detailed list of what we fixed in this release.

Prevents Disk Utility from hanging macOS when erasing a SoftRAID disk

Since around macOS 10.11, a user could get Apple’s Disk Utility program to hang by selecting a SoftRAID formatted disk and erasing it. They could then force quit Disk Utility, but the Mac was left in an unstable state which did not get fixed until the Mac was rebooted. If the disk remained attached, any application which subsequently tried to access the disk would hang (e.g., Disk Utility or SoftRAID). The Mac would also hang when the user attempted a shutdown or restart, requiring a forced restart by holding down the power button.

After trying many different techniques, we finally figured out how to get macOS not to enter this state. Users must still unmount SoftRAID volumes in the Finder before erasing a disk using Disk Utility as Apple’s program does not understand the connection between SoftRAID volumes and disks.

Prevents a kernel panic when a SoftRAID disk is connected via a USB-A port on an M1 Macs

Ever since the M1 Macs shipped we have known about a kernel panic that occurred when a SoftRAID volume on a USB disk or enclosure is attached to the USB-A port on these new Macs. After lots of research and testing, we figured out how to change the SoftRAID driver so that this kernel panic no longer occurs. It was a simple change but so hard to find.

Prevents a kernel panic when a SoftRAID Time Machine volume is disconnected

If a user disconnected a SoftRAID volume which is used as a destination for Time Machine backups, before shutting down the Mac, a kernel panic would occur. This was another one that was hard to figure out, but we now have a fix in the SoftRAID driver which works 100% of the time.

Fixes an occasional kernel panic with heavy i/o

While trying to track down another bug, we found that the Mac would kernel panic after 4 – 6 hours of sustained, heavy i/o. This only happened on Accelsior 4M2 and 8M2 cards which were installed inside a 2019 Mac Pro and not if the Accelsior cards were in a Helios or ThunderBay Flex 8. During our tests, the SoftRAID volume could perform 200 – 400 million reads and writes before the kernel panic occurred. We figured out that this problem happened only when 2 reads or writes happened really close together in a certain specific order. SoftRAID version 6.2.1 contains code to keep this condition from occurring and therefore prevents these kernel panics. We can now run this test for 3 days without encountering this problem.

Reenables validating SoftRAID nonRAID, RAID 0, 1 and 1+0 volumes

Our users reported that they were no longer able to validate nonRAID, RAID 0, 1, and 1+0 volumes. This bug was inadvertently introduced in the move to SoftRAID version 6.

Fixes a bug that caused the SoftRAID Monitor to display the “Volume Locked” dialog

After macOS 10.12 started shipping, users started encountering volumes that became corrupted while in use. We spent months investigating this issue and finally determined that it was caused by a disk ID in the OS being reassigned to a different physical disk while in use. After this, all reads and writes which were supposed to go to the first disk would go to the second disk, and all reads and writes to the second would go to the first. With a RAID volume, this very quickly results in a corrupted volume.

As you can imagine, we spent months trying to duplicate and gather information from users. We also scoured the SoftRAID driver source code looking for what could be going wrong. Then we discovered a user who had it occur with AppleRAID and another who had it occur with a Disk Utility nonRAID volume. Mark, one of our customer support engineers, discovered that if a user kept disks from going to sleep, this problem no longer occurred.

We then figured out how to detect this condition as it was occurring by occasionally reading from the physical disk and making sure the disk’s unique ID agreed with the value read when the disk was first connected. If these two values are not the same, the SoftRAID driver locks all volumes on the disk and the SoftRAID Monitor displays a warning dialog.

Unfortunately, this driver code was mistakenly marking some volumes as locked for a small number of users. This condition is now fixed in this version of the SoftRAID driver.

No more unmountable exFAT volumes

This one slipped by when we originally added support for exFAT volumes. If a user entered a volume name that was longer than 11 characters either when they were creating an exFAT volume or erasing one, the volume would be unmountable. We fixed this by checking the length of the volume name before creating or erasing the volume.

Other articles you may like:

• OWC Radio: All Drives Fail – Tim Standing Talks SoftRAID6 and Pizza!
• macOS Beta No Longer Required When Using SoftRAID on M1 Macs
• What’s Happening with SoftRAID on M1 Macs?