Notifications
Clear all
Ventura Forum
29
Posts
2
Users
0
Reactions
3,477
Views
Topic starter
RAID is populated with 8 x 4TB SSDs, single volume on RAID4, been running 7.0.1 since January. The update from 7.0 to 7.0.1 caused a similar problem, but I was running Monterey at the time, and it was a MAJOR hassle. Lost data and days of production.
Unmounted/unplugged RAID, cloned the Mac (13.2 was running fine), and then ran the 13.3 update. Rebooted, then plugged in the RAID. Initially, only 3 disks of 8 were even visible in Disk Utility. Then after about 5 minutes another 2 showed up. 15 minutes after that, the remaining 3 showed up. I did not attempt to launch SoftRAID prior to all 8 disks becoming available, due to previous experience.
Finally launched SoftRAID - all 8 disks are there, properly identified, all show 'no errors'. Attempts to mount the volume (right-click, select Mount) shows an attempt to mount, but it fails silently after about a minute and reverts to 'unmounted'
My IT director was already giving me the side-eye... who's got a good solution?
Posted : 27/03/2023 2:30 pm
There are no more SoftRAID driver loading issues with 13.3. So the volume directory must be damaged. I am concerned about the drives taking so long to spin up. that would be a enclosure/drive issue, perhaps.
Please attach a SoftRAID tech support file. I can take a look.
Posted : 27/03/2023 2:35 pm
Topic starter
Usually on reboot it comes right up. For me, that one Monterey OS update and this Ventura update each caused a massive delay in individual disk recognition.
Posted : 27/03/2023 2:41 pm
Topic starter
If it matters (and I'd like to think it shouldn't), the Thunderbay 8 is connected to an OWC Thunderbolt Hub, which in turn is plugged into an M1 Mini.
Posted : 27/03/2023 2:55 pm
No a dock won't matter. What is doubly strange is the drives were disconnected when you upgraded to 13.3, showing the mounting had nothing to do with this upgrade.
My guess is whatever caused the disks not to show up for so long was involved. This is APFS, unfortunately, so there are no repair tools.
Try one more restart. See if it behaves normally,as far as disks showing up. (you can use SoftRAID to watch, it cannot cause any problem)
does the volume mount after a restart?
I have no idea what can cause SSD's to take 5-15 minutes to show up. that is very strange. Its like they hung or something. I know of no changes in Ventura that could affect them like that.
Posted : 27/03/2023 3:03 pm
Topic starter
Through 2 normal reboots, the disks enumerate quickly. SoftRAID shows all 8, properly identifies them, no errors, volume shows in the right-hand column - the only thing different than normal is that the volume is unmounted. Attempts to mount fail silently.
Posted : 27/03/2023 3:12 pm
Mounting is by MacOS and should be automatic. All the SoftRAID app does is tell the Finder to mount the volume. It does nothing fancy.
BTW: What is the error if you try First Aid in Disk Utility?
This could be bad news (restore from backup, or scan with a recovery app), as APFS has no repair tools that I am aware of.
Posted : 27/03/2023 3:16 pm
Topic starter
Well. This looks bad. Selected the unmounted volume in DU, ran first aid:
Running First Aid on “VideoRAID” (disk13s1)
Checking file system and repairing if necessary and if possible.
Volume is already unmounted.
Performing fsck_apfs -y -x /dev/rdisk13s1
Checking the container superblock.
warning: (oid 0x402) apfs: invalid o_cksum (0x0)
error: (oid 0x402) apfs: found zeroed-out block
warning: checkpoint 61 (xid 15931) failed consistency check
error: (oid 0x401) nr: invalid o_oid (0x405)
error: (oid 0x401) nr: invalid o_type (0x80000002, expected 0x80000011)
error: verification/reading of the nx_reaper object failed: Illegal byte sequence
warning: checkpoint 59 (xid 15930) failed consistency check
error: (oid 0x402) apfs: invalid o_oid (0x19e44c4)
error: (oid 0x402) apfs: invalid o_xid (0x3d99, expected 0x3e39)
error: (oid 0x402) apfs: invalid o_type (0x40000003, expected 0xd)
error: (oid 0x402) apfs: invalid o_type (0x40000003, expected 0xd)
warning: checkpoint 57 (xid 15929) failed consistency check
error: checkpoint map o_xid (0x3da2) doesn't match checkpoint superblock o_xid (0x3e38)
warning: checkpoint 55 (xid 15928) checkpoint map is invalid
error: (oid 0x19e32b4) om: invalid o_oid (0xdb6f)
error: (oid 0x19e32b4) om: invalid o_xid (0x3de6)
error: (oid 0x19e32b4) om: invalid o_type (0x3, expected 0x4000000b)
error: (oid 0x19e32b4) om: invalid o_type (0x3, expected 0x4000000b)
error: verification/reading of the omap object failed: Illegal byte sequence
warning: checkpoint 53 (xid 15777) failed consistency check
error: (oid 0x33) cpm: invalid o_xid (0x3e36)
warning: checkpoint 51 (xid 15776) checkpoint map is invalid
error: (oid 0x401) nr: invalid o_oid (0xd006)
error: (oid 0x401) nr: invalid o_type (0x80000003, expected 0x80000011)
error: verification/reading of the nx_reaper object failed: Illegal byte sequence
warning: checkpoint 49 (xid 15925) failed consistency check
Checking the checkpoint with transaction ID 15924.
Checking the space manager.
error: (oid 0x76fb) cab: invalid o_type (0x40000007, expected 0x40000006)
error: failed to read spaceman cab 0 at address 0x76fb
Space manager is invalid.
The volume /dev/rdisk13s1 could not be verified completely.
File system check exit code is 8.
Restoring the original state found as unmounted.
File system verify or repair failed. : (-69845)
Operation failed…
Posted : 27/03/2023 3:20 pm
Topic starter
I was forced to waste half my Christmas vacation over this box. If I need to wipe it again, it's going back for a refund.
Posted : 27/03/2023 3:25 pm
where did you get those drives from? we do not sell them. Drives that take 3-15 minutes to appear are not "right".
This may be a drive issue, rather than an "enclosure" issue. I certainly understand the sentiment, however.
One comment I have seen, is connecting an APFS volume that does not mount, to another computer. That has worked for a few users, for reasons I do not understand.
Have the drives ever taken this long to power up before?
Posted : 27/03/2023 3:37 pm
Topic starter
I'll try to mount it on another machine. The drives themselves are Crucial MX500 4TB. This is the only box that I've had this kind of issue, and this is the second time, right after an OS point upgrade. I use these drives in several other enclosures and they always mount immediately. I'll let you know if it actually mounts on the other Mac.
Posted : 27/03/2023 3:43 pm
Weird that disconnecting the drives before a macOS upgrade could have any impact. There is zero SoftRAID volume data in the System. All partition map data is on the drives themselves. MacOS handles all the file system transfers.
while its clear this happened the mechanism is totally obscure, outside of the 3-15 minute power up for the SSD's, which is clearly a problem. Our enclosures also power all drives on at the same time, so was not something from the enclosure power supply. Extremely weird.
Posted : 27/03/2023 3:49 pm
Topic starter
No luck on the other machine - all damage, no good news. So long, OWC.
Posted : 27/03/2023 3:54 pm
I have a theory on the drives. They were using TRIM to trim the deleted data. If there was a LOT of data to TRIM, it could take quite a while. It should have been ongoing, but i can envision this happening after a restart. That should not affect the data, however, assuming that Crucial did a good job with their MacOS implementation.
How long since the last time this volume was powered off? Has it been a while?
Posted : 27/03/2023 5:01 pm
Topic starter
I reboot periodically, typically a couple of times / month - I'll boot into recovery to check my internal. On restart it usually pops right up. The two times it didn't mount, was directly after point updates to the OS. This one, and once in December with a Monterey update. It was fine for the Monterey to Ventura upgrade, 13.1, 13.2...
Posted : 27/03/2023 5:14 pm
Page 1 / 2
Next
