I just came across this issue and discovered it's a very serious problem. Drives that worked fine in Big Sur now take minutes to mount, if they mount at all, and are similarly difficult to unmount. Disk Utility not only has problems with First Aid but cannot even erase some HD drives. Moreover, problem is also evident on SSD drives.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Monterey cannot erase external SSD
- Thread starter darkinners
- Start date
- Sort by reaction score
So the mounting issue is with some usb 3.1 gen 2 enclosures/drives and I do have a 3rd party one that won't mount when directly connected to the M1 Pro. However, it will mount when connected to a thunderbolt dock that is connected to the M1 Pro.
Sucks to have to always use the dock with such portable drives but could be a temporary workaround for now.
Sucks to have to always use the dock with such portable drives but could be a temporary workaround for now.
I have these issues using a Samsung T5 2Tb SSD drive. It works perfectly on my 2013 MBP on Catalina but will not function properly on my MBP M1 Max 64gb Monterey 12.1. The SSD is a USB-c 3.1. I ordered a new Thunderbolt 3 drive to see if that has same problems that the USB-c 3.1 does. It comes in on Thursday and I'll report if any issues.
On a side note what drive did you put in your X5? I have a 500Gb version that I would like to upgrade. Not sure which model/make of drive to put in it.
I may have news to report... I'm no expert but here is what I did. Synopsis: Upgraded from 2013 MBP to 2021 MBP M1 Max 64gb 2Tb. My Samsung T5 SSD worked perfectly on the old MBP. Once I got Photoshop and Lightroom installed on the new M1, I tried to Import photos into Lightroom from the Samsung T5. No dice. It looked as if it mounted. It saw the files. It "kind of" imported them but when I tried to do anything with them, I got bad file errors or corrupted file error. So, I exited Lightroom and simply tried to move 1 file from the SSD to the Desktop. No dice. It said the file was corrupted. ARG! I attempted to eject the drive but it wouldn't eject and asked me if I wanted to Force Eject. It wouldn't even do that. Unplug *gasp* and reboot. Took the SSD immediately to the old MBP and everything worked fine. My photos were safe. *phew*... So.. Thinking me new MBP M1 Max is crap with Monterey.. I'm searching for solutions. I Though I'd buy a Thunderbolt 3 SSD and see how that worked; fully expecting it not to work and I'd have my unhappy butt down to the Apple Store with both drives and have THEM explain. Well.... The drive came in today and I plugged it in.. It worked perfectly. PERFECTLY. So, back on the old MBP, I copied the files from the Samsung T5 to a SanDisk SD card. The new MBP has a card slot (YES!) and I was able to copy all the photos from the SD to the Thunderbolt SSD on the M1 Max. Perfect.
All this got me thinking as the new drive had a cord that had '3' (Thunderbolt 3) on it. I got everything squared away and unmounted all the externals. I used the Thunderbolt cord in the Samsung SSD, plugged it in... and IT WORKED PERFECTLY! It did mount slower (10 seconds) as I expected because it's a slower device, but everything worked after that. All I need now is another Thunderbolt cord to have both 2Tb drives online. Hope my non-professional insight may help y'all some. At least something to try anyway. Cheers all...
All this got me thinking as the new drive had a cord that had '3' (Thunderbolt 3) on it. I got everything squared away and unmounted all the externals. I used the Thunderbolt cord in the Samsung SSD, plugged it in... and IT WORKED PERFECTLY! It did mount slower (10 seconds) as I expected because it's a slower device, but everything worked after that. All I need now is another Thunderbolt cord to have both 2Tb drives online. Hope my non-professional insight may help y'all some. At least something to try anyway. Cheers all...
Pretty sure it was a 1TB Samsung 980. I was a bit disappointed by the 1700s I was hoping for the 2500's the X5 was rated for.
Problem is still present on the latest beta (12.3 Beta (21E5212f)), I went through countless threads on various forums, certain reported that the TB3 cable resolved the issues for them.
I had some spare points I could trade for such cable (original Apple TB 3 Cable 0.8m), yet it still did not resolve the problem of utterly slow speeds (approx. only 10MB/s instead of usual 450MB/s) on my LaCie Mobile SSD 2TB (https://www.macrumors.com/review/lacie-mobile-ssd/).
I had some spare points I could trade for such cable (original Apple TB 3 Cable 0.8m), yet it still did not resolve the problem of utterly slow speeds (approx. only 10MB/s instead of usual 450MB/s) on my LaCie Mobile SSD 2TB (https://www.macrumors.com/review/lacie-mobile-ssd/).
I was pleased to find out that after installing 12.4 I'm getting the usual speeds of the LaCie Mobile SSD (writing at approx. 450MB/s). Before the update I was getting writing speeds at approx. 8MB/s tops.
There is an incompatibility between Monterey, VIA Labs, and HDD/SDD > 4TB. If you try your enclosure using storage < 4TB, it will work.
I posted earlier about issues where Monterey would not read or format my Samsung 4TB EVO 860 SSD. Big Sur worked perfectly with it but multiple Monterey machines would not. I used it as a boot drive on a 2019 iMac.
I upgraded to a MacStudio with 4TB SSD and it would not read this drive either. Had to migrate from a 5TB HDD.
I finally had some time to experiment some more. I connected the drive to a Monterey 12.4 2019 Intel i9 MBP.
I formatted it to EXFAT GUID Partition. It took at least 30 minutes to an hour. Just let it crank.
It finally completed. Worked fine. I then formatted it APFS GUID Partition. Formatted quickly as expected. Works fine - 500+MB read/write on Blackmagic.
Currently using as a backup drive with MacStudio - no issues.
I will probably rotate all my SSDs and HDDs through this process to make sure they are Monterey compatible. Some of my HDDs seem a little too slow/quirky on Monterey.
Just remember the EXFAT format can take a long time.
NOTE: I used a USB 3.x cable for this.
I upgraded to a MacStudio with 4TB SSD and it would not read this drive either. Had to migrate from a 5TB HDD.
I finally had some time to experiment some more. I connected the drive to a Monterey 12.4 2019 Intel i9 MBP.
I formatted it to EXFAT GUID Partition. It took at least 30 minutes to an hour. Just let it crank.
It finally completed. Worked fine. I then formatted it APFS GUID Partition. Formatted quickly as expected. Works fine - 500+MB read/write on Blackmagic.
Currently using as a backup drive with MacStudio - no issues.
I will probably rotate all my SSDs and HDDs through this process to make sure they are Monterey compatible. Some of my HDDs seem a little too slow/quirky on Monterey.
Just remember the EXFAT format can take a long time.
NOTE: I used a USB 3.x cable for this.
The easiest way to erase any storage drive on Mac is by using the Disk Utility feature. But sometimes, Mac Disk Utility can’t erase the drive due to various reasons. However, the issue can be fixed using the below DIY methods:
1. Erase the Drive by Enabling "Show All Devices"
2. Use First Aid to Repair Drive before Erasing
3. Use Recovery Mode to Erase the Drive
4. Erase Data using 3rd party tool like BitRaser File Eraser
Hope it will help!
1. Erase the Drive by Enabling "Show All Devices"
2. Use First Aid to Repair Drive before Erasing
3. Use Recovery Mode to Erase the Drive
4. Erase Data using 3rd party tool like BitRaser File Eraser
Hope it will help!
I just hit this issue (which I unfortunately did not know about previously) with a 4TB external Crucial MX500 SSD connected via a Sabrent USB to SATA, on a 2015 iMac after an upgrade from Big Sur to Monterey. The drive must have briefly worked after the restart since I saw it showing up as mounted, but it showed no files or directories anymore. The machine had been sitting for a while after the upgrade. Once I saw the empty directory, I immediately unplugged the drive to avoid having it persist the empty state back to the disk, and was hoping it would be normal after reconnecting, but instead it could no longer read the APFS partition at all. Upon examining the raw data, I found that the first 105 sectors (4K sectorsize) are now all zero in that partition, which is the 2nd partition.
I had a 2nd external drive, also APFS, also MX500 but only 2TB, hooked up via a similar Sabrent USB device, but it seems to be okay.
One big difference between the SSDs (besides 4TB vs 2TB) is that the 4TB SSD was using a 4K "native" sector size with that Sabrent controller. (presumably emulated by joining 8 512 byte sectors and presenting them as 4K via the USB interface). I had run into issues with that in the past anyway because it meant that I couldn't use that SSD with a different USB controller without changing the partition table to reflect the sector offsets as multiples of 8. (if moving it over without reformatting; I discovered this last year because I had formatted and populated the drive from a different USB controller first, so it had 512b sectors, then when it seemed unreadable using the Sabrent, and I discovered it was showing up as a 4K device, I modified the partition table to have the correct offsets and sizes for 4K instead of 512b and it had been working fine every since in Big Sur)
I notice from the system logs that a bunch of TRIMs did get issued to the drive. (I believe I had trimforce enabled prior to the upgrade and presumably it stayed enabled) There were some TRIM errors though. See logs at the end of this post.
So I'm wondering if Monterey is having some problem with TRIM now on external SSDs that are presenting a 4K sector size (or more specifically ones that might be really native 512b but have a controller presenting them as 4K).
If the TRIM is ending up in the wrong place or is the wrong size, that might explain why I'm seeing a large zeroed region right at the start of the APFS partition.
I was using encrypted APFS, so I'm not sure if there's any way to recover the rest of it when the start of it is zeroed, and I also don't know if random zeroing happened throughout the entire partition if it's trimming the wrong places.
Trim logs:
2022-10-24 18:14:06.034369-0400 0x5552 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk4 scan took 0.002236 s (no trims)
2022-10-24 18:14:06.034379-0400 0x5552 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk4 scan took 0.000006 s, trims took 0.000000 s
2022-10-24 18:14:07.092788-0400 0x561c Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk5 scan took 0.000679 s (no trims)
2022-10-24 18:14:07.092797-0400 0x561c Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk5 scan took 0.000005 s, trims took 0.000000 s
2022-10-24 18:14:07.147691-0400 0x55c1 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk4 scan took 0.779199 s (no trims)
2022-10-24 18:14:12.921254-0400 0x55c1 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk4 scan took 5.773553 s, trims took 4.995204 s
2022-10-24 18:14:12.921264-0400 0x55c1 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3164: disk4 60485175 blocks trimmed in 150672 extents (33 us/trim, 30163 trims/s)
2022-10-24 18:14:12.921268-0400 0x55c1 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3167: disk4 trim distribution 1:58638 2+:34318 4+:27923 16+:11442 64+:12070 256+:6281
2022-10-24 18:14:15.704651-0400 0x5a99 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk5 scan took 0.953756 s (no trims)
2022-10-24 18:15:02.820673-0400 0x5a99 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk5 scan took 47.116016 s, trims took 46.245133 s
2022-10-24 18:15:02.820678-0400 0x5a99 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3164: disk5 668705095 blocks trimmed in 588 extents (78648 us/trim, 12 trims/s)
2022-10-24 18:15:02.820680-0400 0x5a99 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3167: disk5 trim distribution 1:378 2+:42 4+:6 16+:0 64+:0 256+:162
2022-10-24 18:15:02.820682-0400 0x5a99 Default 0x0 0 0 kernel: (apfs) nx_mount_trim_thread:874: disk5 *** error trim'ing free blocks: 92
2022-10-24 20:23:50.631094-0400 0x1a3ce Default 0x0 0 0 kernel: (apfs) _vnode_dev_unmap_flush_and_unlock:1624: disk5 trim'ing 7 blocks from trim_list failed w/: 6 (entry 0:0 ; 0:0)
2022-10-24 20:23:50.631118-0400 0x1a3ce Default 0x0 0 0 kernel: (apfs) _vnode_dev_unmap_flush_and_unlock:1624: disk5 trim'ing 7 blocks from trim_list failed w/: 6 (entry 0:0 ; 0:0)
2022-10-24 20:25:14.474095-0400 0x1a79c Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.722715 s (no trims)
2022-10-24 20:25:21.077005-0400 0x1a79c Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk3 scan took 6.602901 s, trims took 5.778378 s
2022-10-24 20:25:21.077012-0400 0x1a79c Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3164: disk3 60498708 blocks trimmed in 149263 extents (38 us/trim, 25831 trims/s)
2022-10-24 20:25:21.077014-0400 0x1a79c Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3167: disk3 trim distribution 1:57710 2+:33877 4+:27849 16+:11443 64+:12083 256+:6301
I had a 2nd external drive, also APFS, also MX500 but only 2TB, hooked up via a similar Sabrent USB device, but it seems to be okay.
One big difference between the SSDs (besides 4TB vs 2TB) is that the 4TB SSD was using a 4K "native" sector size with that Sabrent controller. (presumably emulated by joining 8 512 byte sectors and presenting them as 4K via the USB interface). I had run into issues with that in the past anyway because it meant that I couldn't use that SSD with a different USB controller without changing the partition table to reflect the sector offsets as multiples of 8. (if moving it over without reformatting; I discovered this last year because I had formatted and populated the drive from a different USB controller first, so it had 512b sectors, then when it seemed unreadable using the Sabrent, and I discovered it was showing up as a 4K device, I modified the partition table to have the correct offsets and sizes for 4K instead of 512b and it had been working fine every since in Big Sur)
I notice from the system logs that a bunch of TRIMs did get issued to the drive. (I believe I had trimforce enabled prior to the upgrade and presumably it stayed enabled) There were some TRIM errors though. See logs at the end of this post.
So I'm wondering if Monterey is having some problem with TRIM now on external SSDs that are presenting a 4K sector size (or more specifically ones that might be really native 512b but have a controller presenting them as 4K).
If the TRIM is ending up in the wrong place or is the wrong size, that might explain why I'm seeing a large zeroed region right at the start of the APFS partition.
I was using encrypted APFS, so I'm not sure if there's any way to recover the rest of it when the start of it is zeroed, and I also don't know if random zeroing happened throughout the entire partition if it's trimming the wrong places.
Trim logs:
2022-10-24 18:14:06.034369-0400 0x5552 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk4 scan took 0.002236 s (no trims)
2022-10-24 18:14:06.034379-0400 0x5552 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk4 scan took 0.000006 s, trims took 0.000000 s
2022-10-24 18:14:07.092788-0400 0x561c Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk5 scan took 0.000679 s (no trims)
2022-10-24 18:14:07.092797-0400 0x561c Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk5 scan took 0.000005 s, trims took 0.000000 s
2022-10-24 18:14:07.147691-0400 0x55c1 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk4 scan took 0.779199 s (no trims)
2022-10-24 18:14:12.921254-0400 0x55c1 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk4 scan took 5.773553 s, trims took 4.995204 s
2022-10-24 18:14:12.921264-0400 0x55c1 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3164: disk4 60485175 blocks trimmed in 150672 extents (33 us/trim, 30163 trims/s)
2022-10-24 18:14:12.921268-0400 0x55c1 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3167: disk4 trim distribution 1:58638 2+:34318 4+:27923 16+:11442 64+:12070 256+:6281
2022-10-24 18:14:15.704651-0400 0x5a99 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk5 scan took 0.953756 s (no trims)
2022-10-24 18:15:02.820673-0400 0x5a99 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk5 scan took 47.116016 s, trims took 46.245133 s
2022-10-24 18:15:02.820678-0400 0x5a99 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3164: disk5 668705095 blocks trimmed in 588 extents (78648 us/trim, 12 trims/s)
2022-10-24 18:15:02.820680-0400 0x5a99 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3167: disk5 trim distribution 1:378 2+:42 4+:6 16+:0 64+:0 256+:162
2022-10-24 18:15:02.820682-0400 0x5a99 Default 0x0 0 0 kernel: (apfs) nx_mount_trim_thread:874: disk5 *** error trim'ing free blocks: 92
2022-10-24 20:23:50.631094-0400 0x1a3ce Default 0x0 0 0 kernel: (apfs) _vnode_dev_unmap_flush_and_unlock:1624: disk5 trim'ing 7 blocks from trim_list failed w/: 6 (entry 0:0 ; 0:0)
2022-10-24 20:23:50.631118-0400 0x1a3ce Default 0x0 0 0 kernel: (apfs) _vnode_dev_unmap_flush_and_unlock:1624: disk5 trim'ing 7 blocks from trim_list failed w/: 6 (entry 0:0 ; 0:0)
2022-10-24 20:25:14.474095-0400 0x1a79c Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.722715 s (no trims)
2022-10-24 20:25:21.077005-0400 0x1a79c Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk3 scan took 6.602901 s, trims took 5.778378 s
2022-10-24 20:25:21.077012-0400 0x1a79c Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3164: disk3 60498708 blocks trimmed in 149263 extents (38 us/trim, 25831 trims/s)
2022-10-24 20:25:21.077014-0400 0x1a79c Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3167: disk3 trim distribution 1:57710 2+:33877 4+:27849 16+:11443 64+:12083 256+:6301
So I just found this also... .which pre-dates the failed TRIM. It also makes me wonder why it's even attempting a TRIM *after* finding a corruption. That seems guaranteed to lead to unrecoverable data loss. Also note that this is immediately after a supposedly successful TRIM of disk5:
2022-10-24 18:14:15.713195-0400 0x2db Default 0x0 109 0 diskarbitrationd: [com.apple.DiskArbitration.diskarbitrationd:default] mounted disk, id = /dev/disk5s1, success.
2022-10-24 18:14:15.828248-0400 0x59f Default 0x0 0 0 kernel: (apfs) obj_checksum_verify:5208: disk5s1 failed: cksum 0xce88a17f1f90367d, oid 0x1de14984ab64a3f2, o_xid 0xc9e2e1952e79e10b, o_type 0x5f29d809, o_subtype 0xb1e9ddff, size 4096
2022-10-24 18:14:15.828254-0400 0x59f Default 0x0 0 0 kernel: (apfs) nx_corruption_detected_int:55: disk5 Container corruption detected by obj_checksum_verify:5216!
2022-10-24 18:14:15.828258-0400 0x59f Default 0x0 0 0 kernel: (apfs) obj_read:4820: disk5s1 oid 0x9bfa flags 0x10000523 0x0 type 0x10000003/0xe paddr 0x22b14 error verifying checksum
2022-10-24 18:14:15.830103-0400 0x59f Default 0x0 0 0 kernel: (apfs) obj_checksum_verify:5208: disk5s1 failed: cksum 0x425358b58d72f897, oid 0xb885bfab077bb5b1, o_xid 0x76b41f8e98f6f56f, o_type 0x704bb0da, o_subtype 0xa6cd2f42, size 4096
2022-10-24 18:14:15.830109-0400 0x59f Default 0x0 0 0 kernel: (apfs) nx_corruption_detected_int:55: disk5 Container corruption detected by obj_checksum_verify:5216!
2022-10-24 18:14:15.830113-0400 0x59f Default 0x0 0 0 kernel: (apfs) obj_read:4820: disk5s1 oid 0x905d flags 0x10000523 0x0 type 0x10000003/0xe paddr 0x1d965 error verifying checksum
<thousands of errors like this follow>
I think I had the timeline slightly off... the corruptions are detected first, then TRIM commands get issued. But why oh why Apple are you trying to TRIM (and thus discard data entirely) on a drive that you can't read properly? That would seem to explain why the disks end up broken even when used on Big Sur again.
So I'm wondering if the initial corruption is related to the 4K emulated sector size, and then this somehow leads to a destructive TRIM.
I think I need to turn trimforce off on Monterey machines now.
These are the specs of the USB to SATA adapter that was being used on the 4TB drive that got corrupted after the Monterey upgrade:
Product ID: 0x1561
Vendor ID: 0x152d (JMicron Technology Corp.)
Version: 2.04
Speed: Up to 5 Gb/s
Manufacturer: SABRENT
Also, I'm no longer convinced that a low-level TRIM got issued to the drive since it was via a USB adapter, but it appears at least that trimming occurred within the container, and perhaps some mis-mapping with the 4K sector size led to the wrong area being zeroed.
Product ID: 0x1561
Vendor ID: 0x152d (JMicron Technology Corp.)
Version: 2.04
Speed: Up to 5 Gb/s
Manufacturer: SABRENT
Also, I'm no longer convinced that a low-level TRIM got issued to the drive since it was via a USB adapter, but it appears at least that trimming occurred within the container, and perhaps some mis-mapping with the 4K sector size led to the wrong area being zeroed.
I can't go beyond Monterey on that iMac, so I have to figure out exactly what conditions cause this, and which combinations of adapters and drives are safe before I can even trust my external drives again. (and meanwhile, I've totally lost what was on the 4TB SSD as far as I can tell-- no attempts to recover it have worked so far)
My laptop could go to Ventura though, so it would still be good to know the answer to that question.
So I've noticed that all of the USB->SATA adapters I've tried have UASP, and currently I don't know of a way to disable that to see if that's related to the problem. But I'm wondering if Monterey has increased the queue depth over UASP compared to what Big Sur used? And then with my Sabrent/JMicron adapter that is emulating 4K sectors, that means each UASP I/O is getting converted to 8 device I/Os over SATA, and the SATA NCQ has a queue depth limit of 31. So it might not be handling the overload well.
I'm now seeing the problem (or another problem) with other adapters as well, just less often, so it doesn't show up during the initial format. It can take an hour or more of constant usage to show up, but it's still a corruption that leaves the filesystem damaged and unmountable once it happens. The Sabrent/Jmicron (152b:1561) was emulating 4K native sectors and with that adapter the problem would show up immediately during disk format and existing formatted drives would quickly get corrupted in unrecoverable ways. So this isn't nearly as bad as that, but in some ways it's worse, since it appears to work, and then later gets corrupted.
The adapter that just led to another failure was a newer Sabrent using a VIA chipset (2109:0715), and this one is presenting 512 byte sectors. But after hours of I/O load, it still corrupted APFS.
What I'm doing for load testing is copying a few GB of folder content to the drive first after it's formatted with APFS (I'm using encrypted APFS, if that makes a difference for this issue). And then I'm running Blackmagic Speed Test on the drive so it's constantly alternating between write and read performance tests. After a while it fails and then the drive is corrupted and won't re-mount.
Again, I've never seen any problem like this under Big Sur.
And it's happening under Monterey on both a Late 2015 iMac, and a 2018 MacBook Pro laptop.
I almost updated my 2018 Mac Mini but I stopped once this issue showed up and now don't want to risk it.
I'm debating downgrading the other machines, especially if I can't find a 100% safe USB adapter for SATA for external drives.
One thing that really concerns me is that even if there are issues that can occasionally lead to an I/O error over USB3.0, why is it leading to a series of errors and eventually corruption of the APFS? It seems like there's some new bug that allows APFS to continue writing after a corruption, using corrupted information, so that it starts becoming destructive to the disk. It's possible that the original problem is related to the hardware, and that various adapters have their issues that make them not 100% reliable at all times, and it's possible that the I/O errors were already occasionally occurring under BigSur, but that they didn't lead to an ongoing snowball effect like they seem to be causing now. If there are multiple errors detected, the filesystem should go read-only or offline before it risks destroying the content in an unrecoverable way. I'd rather have my disks unwritable or even unmountable under Monterey than have them destroyed in a way that I can't even recover again from BigSur.
The adapter that just led to another failure was a newer Sabrent using a VIA chipset (2109:0715), and this one is presenting 512 byte sectors. But after hours of I/O load, it still corrupted APFS.
What I'm doing for load testing is copying a few GB of folder content to the drive first after it's formatted with APFS (I'm using encrypted APFS, if that makes a difference for this issue). And then I'm running Blackmagic Speed Test on the drive so it's constantly alternating between write and read performance tests. After a while it fails and then the drive is corrupted and won't re-mount.
Again, I've never seen any problem like this under Big Sur.
And it's happening under Monterey on both a Late 2015 iMac, and a 2018 MacBook Pro laptop.
I almost updated my 2018 Mac Mini but I stopped once this issue showed up and now don't want to risk it.
I'm debating downgrading the other machines, especially if I can't find a 100% safe USB adapter for SATA for external drives.
One thing that really concerns me is that even if there are issues that can occasionally lead to an I/O error over USB3.0, why is it leading to a series of errors and eventually corruption of the APFS? It seems like there's some new bug that allows APFS to continue writing after a corruption, using corrupted information, so that it starts becoming destructive to the disk. It's possible that the original problem is related to the hardware, and that various adapters have their issues that make them not 100% reliable at all times, and it's possible that the I/O errors were already occasionally occurring under BigSur, but that they didn't lead to an ongoing snowball effect like they seem to be causing now. If there are multiple errors detected, the filesystem should go read-only or offline before it risks destroying the content in an unrecoverable way. I'd rather have my disks unwritable or even unmountable under Monterey than have them destroyed in a way that I can't even recover again from BigSur.
After many reformats here's what I've found so far:
- I can reproduce this behavior in about 5 to 15 minutes with a Crucial 4TB SSD and Sabrent USB adapter with the VIA chipset (2109:0715) by simply running the Blackmagic Speedtest on the newly formatted APFS filesystem. (this is a device that otherwise appears at first to work since it doesn't give an error when formatting; so without hammering on it with constant I/O, it might well get mistaken for a working setup, used for months, and then lead to unrecoverable data loss)
- it doesn't matter if APFS is encrypted or not
- if I use HFS+ (Macos Extended) the problem doesn't show up
- explicitly running "trimforce disable" (in case it was on; not sure if it was previously) and then rebooting doesn't seem to have done anything to help fix the issue
- after the speedtest fails with an error, if I unmount the filesystem, it can never be mounted again, even after rebooting, since the APFS partition has become corrupted (although at least in these cases it still recognizes it as APFS; when my original failure occurred with the older Sabrent/Jmicron adapter and the 4K sector emulation, it caused the start of the APFS partition to get zeroed out so it didn't even get seen as APFS anymore, and since it was encrypted, nothing was recoverable)
Note: I am not using any USB HUB in these tests. These are direct-connect. I've heard that some hubs were suspected as the issue, but that's certainly not the case here. However, I've also heard that some older hubs "fix" the issue. I'm wondering if that's because they don't support UASP, and perhaps the issue only occurs over UASP.
- I can reproduce this behavior in about 5 to 15 minutes with a Crucial 4TB SSD and Sabrent USB adapter with the VIA chipset (2109:0715) by simply running the Blackmagic Speedtest on the newly formatted APFS filesystem. (this is a device that otherwise appears at first to work since it doesn't give an error when formatting; so without hammering on it with constant I/O, it might well get mistaken for a working setup, used for months, and then lead to unrecoverable data loss)
- it doesn't matter if APFS is encrypted or not
- if I use HFS+ (Macos Extended) the problem doesn't show up
- explicitly running "trimforce disable" (in case it was on; not sure if it was previously) and then rebooting doesn't seem to have done anything to help fix the issue
- after the speedtest fails with an error, if I unmount the filesystem, it can never be mounted again, even after rebooting, since the APFS partition has become corrupted (although at least in these cases it still recognizes it as APFS; when my original failure occurred with the older Sabrent/Jmicron adapter and the 4K sector emulation, it caused the start of the APFS partition to get zeroed out so it didn't even get seen as APFS anymore, and since it was encrypted, nothing was recoverable)
Note: I am not using any USB HUB in these tests. These are direct-connect. I've heard that some hubs were suspected as the issue, but that's certainly not the case here. However, I've also heard that some older hubs "fix" the issue. I'm wondering if that's because they don't support UASP, and perhaps the issue only occurs over UASP.
So I see that others have had trouble with this exact device (VIA 2109:0715) on Linux with UAS (UASP) and had to essentially blacklist it for that functionality:
Is there any sort of device blacklist for MacOS that we can add to so that these devices will still at least work for accessing drives slowly without UASP, but won't end up doing something that could corrupt their contents under APFS?
We might want to start by just adding the entire current Linux UAS blacklist and then only removing devices from it if someone has extensively tested them under Monterey and/or Ventura. I'm still concerned though that any failure is leading to a complete destructive corruption of the APFS filesystem where none of it can ever be accessed again even from another adapter or OS. It doesn't seem like that should be happening even if the adapter is failing. The scope of the error should be more limited, not leading to a cascading filesystem corruption.
So far I'm having good luck (no errors yet under hours of ongoing high write activity while also running the Blackmagic speed test) with a Sabrent/Jmicron adapter with a 4TB SSD. Note that my original problem was also from a Sabrent/Jmicron that was supposedly the exact same product, but it's not. The original failed one (which also imposed a 4K emulated sector size) was a 152d:1561 v2.04, which also shows up as a known problematic device for UAS on Linux blacklists.
The Sabrent/Jmicron that seems to be working so far is a 152d:0576 v12.14, which is limited to 5Gb/s. I've tested on both a 2015 iMac (which has a 5Gb/s USB limit anyway) and a 2018 Macbook Pro (which could theoretically handle 10Gb/s)
Unfortunately I can't currently buy that particular Sabrent device again, at least not easily, since the one being sold as the "same" device now has a VIA chipset (2109:0715) which *does* have problems, although it initially appears to pass the APFS drive erasure test. The corruption on that one shows up later under heavy I/O load (such as running the Black magic speed test for about 15 minutes non-stop) which is more insidious, since a user could easily think it's fine, fill it up with content, maybe use it for a long time and then just have it fail and corrupt the disk later. That's why I'm load-testing them first now, and unfortunately wearing out some of the lifetime of new SSDs in advance just to make sure that the adapters aren't going to fail later at some inconvenient time.
The Sabrent/Jmicron that seems to be working so far is a 152d:0576 v12.14, which is limited to 5Gb/s. I've tested on both a 2015 iMac (which has a 5Gb/s USB limit anyway) and a 2018 Macbook Pro (which could theoretically handle 10Gb/s)
Unfortunately I can't currently buy that particular Sabrent device again, at least not easily, since the one being sold as the "same" device now has a VIA chipset (2109:0715) which *does* have problems, although it initially appears to pass the APFS drive erasure test. The corruption on that one shows up later under heavy I/O load (such as running the Black magic speed test for about 15 minutes non-stop) which is more insidious, since a user could easily think it's fine, fill it up with content, maybe use it for a long time and then just have it fail and corrupt the disk later. That's why I'm load-testing them first now, and unfortunately wearing out some of the lifetime of new SSDs in advance just to make sure that the adapters aren't going to fail later at some inconvenient time.
I just tested a Sabrent/Jmicron (152d:1561) with firmware v2.1.4 (reported as 2.14 in the system info) with Monterey and it still gives errors when formatting APFS. (and that also generates trims in the system log) I also noticed that HFS+ has issues too. A simple format of the entire drive seems to work, but if I attempt to partition it to split it into two 2TB sections, the HFS+ format fails. (but this, interestingly, does not generate trims, and yet it fails; but this device is "special" in the fact that it translates the 512 byte sectors to an emulated 4K sectors size, so there could be additional problems here that aren't on other devices with 512 byte sectors that are showing failures)
I have the exact same issues as described in this thread. Have you tried this enclosure yet?
eshop.macsales.com
I found this suggestion in this thread https://forums.macrumors.com/thread...nclosure.2283434/?post=30642514#post-30642514
I ordered one and I will post my experience as soon as I have it.
OWC Mercury Elite Pro mini with USB-C
Now equipped with USB-C and delivers up to 600 MB/s transfer speeds. Choose between a 2.5-inch hard drive or an SSD, and gain up to 8TB of storage.
I found this suggestion in this thread https://forums.macrumors.com/thread...nclosure.2283434/?post=30642514#post-30642514
I ordered one and I will post my experience as soon as I have it.