Does Monterey Have a Bug with Mounting External Drives & Images?

[fb77]

I've been running into this problem since upgrading to Monterey and having a 4TB external SSD with encrypted APFS corrupted and unrecoverable after the upgrade.

I had posted about my findings so far over on this other related topic about erasing external drives failing under Monterey, since I discovered I could not even format a new 4TB SSD with the Sabrent/Jmicron(4Ke) USB adapter under Monterey:

https://forums.macrumors.com/threads/monterey-cannot-erase-external-ssd.2321713/page-5

However, I've since found that other controllers that at first appear to work (like a Sabrent/VIA adapter) also lead to corruptions later, and I can reproduce them in under 15 minutes by running Blackmagic Speedtest on the newly formatted APFS fileystem.

 

[iDento]

Any updates on Ventura? Is it fixed now?

 

[fb77]

Any updates on Ventura? Is it fixed now?

I suspect that at least part of this might be hard to "fix". Here's my suspicion (not yet confirmed) about what I think is going on: (NOTE: speculation follows) I think that lots of these USB to SATA adapters are less than 100% reliable when under a heavy load, and so when they get pushed with lots of simultaneous I/O over UASP, they experience a temporary failure. Some might even have bugs that lose or corrupt data themselves, but I think in most case it's probably just a temporary I/O error, and thus something Big Sur used to just deal with. Maybe it caused the drive to offline or it just did a retry. Or perhaps Big Sur never pushed these devices hard enough to show the failure in the first place.

But under Monterey I see an ongoing series of errors interspersed with "spaceman" trims from APFS. So there seems to be fairly major bug here with APFS now (or maybe it was there before and just not getting triggered before Monterey) that causes it to keep destroying the filesystem with ongoing activity that writes to it, or at least TRIMs it (or does a UASP "unmap") to keep remove "empty" space that isn't really empty. Once there's a corruption detected, it should really stop and go read-only and not keep writing and trashing the entire filesystem with incorrect knowledge of the format. Especially if (as suspected) the error is caused by a temporary device failure that would probably recover if the device was left idle for a bit. At the very least, there should be a delay and a retry instead of immediately erasing. I worry about what might even happen with the internal APFS filesystems now if they were ever to have a similar temporary hardware glitch.

 

[fb77]

I suspect that at least part of this might be hard to "fix". Here's my suspicion (not yet confirmed) about what I think is going on: (NOTE: speculation follows) I think that lots of these USB to SATA adapters are less than 100% reliable when under a heavy load, and so when they get pushed with lots of simultaneous I/O over UASP, they experience a temporary failure. Some might even have bugs that lose or corrupt data themselves, but I think in most case it's probably just a temporary I/O error, and thus something Big Sur used to just deal with. Maybe it caused the drive to offline or it just did a retry. Or perhaps Big Sur never pushed these devices hard enough to show the failure in the first place.

But under Monterey I see an ongoing series of errors interspersed with "spaceman" trims from APFS. So there seems to be fairly major bug here with APFS now (or maybe it was there before and just not getting triggered before Monterey) that causes it to keep destroying the filesystem with ongoing activity that writes to it, or at least TRIMs it (or does a UASP "unmap") to keep remove "empty" space that isn't really empty. Once there's a corruption detected, it should really stop and go read-only and not keep writing and trashing the entire filesystem with incorrect knowledge of the format. Especially if (as suspected) the error is caused by a temporary device failure that would probably recover if the device was left idle for a bit. At the very least, there should be a delay and a retry instead of immediately erasing. I worry about what might even happen with the internal APFS filesystems now if they were ever to have a similar temporary hardware glitch.

I should also add that I'm not positive whether TRIM (or UASP UNMAP) commands are actually being sent out to the drive over USB, but I saw "spaceman" trimming messages in the system log from APFS. Does anyone know if that only happens when the trim/unmap goes all the way to the drive level? Or is that just a higher-level APFS trim that may or may not turn into an actual device trim?

And if the TRIMs/UNMAPs *are* actually going out to the device, did this also happen under Big Sur for external USB drives, or is this new to Monterey? And if this is new behavior, is it possible some of these USB/SATA adapters aren't handling this properly? For one thing a SATA TRIM/UNMAP on an SSD can cause a big delay in the drive itself. So if there are lots of other UASP device I/Os queued up, or still more being issued, it could cause a timeout, or a full queue that is unable to accept more I/O. It's possible these adapters have various failure modes related to this that aren't being handling well by Monterey.

 

[fb77]

So here's something else that makes me think there's some problem related to TRIM/UNMAP here:

I re-created the corruption with the Sabrent/VIA adapter (2109:0715) and 4TB drive by running Blackmagic Speedtest for a few minutes on a fresh APFS filesystem.

After it showed an error, I immediately did this to view the start of the container partition:
od -x /dev/disk2s2 | head
and it showed me that it was all zeros until "2350000" (octal; so that's 643072 bytes in or 157 4K sectors)

That's the start of the container partition where it needs to have something to describe the container, or it won't even be able to recognize it as an APFS container at all. I know that if I pull the drive out at this point without unmounting, it no longer even recognizes it as an APFS container, let alone being able to decode the contents. So clearly once the error is hit, it is very very bad to pull the drive out. The start of the container has already been zeroed. (and it should never be! That's extremely close to effectively clearing a partition table of an actively mounted drive. Why would MacOS do this? Or is it doing it, or is some TRIM/UNMAP getting scrambled by the adapter and erasing the wrong region?)

However this time I proceeded to do the unmount.
Then I re-examined the start of the partition again:
od -x /dev/disk2s2 | head
and lo and behold, it now "magically" had non-zero content right at the start.

And sure enough, it still shows up as an APFS container, and thus as /disk/disk3s1 for the APFS volume inside of it.

It still won't mount, since it's already corrupted inside the container, but at least the container header itself is intact now.

So this means MacOS knew that something was still supposed to be written there, and unmounting flushed back the latest updates to the descriptor at the start of the container. (presumably the final state of it and showing that it's now cleanly unmounted)

So why was it zeroed when it was still actively in use, after the corruption occurred? It seems highly unlikely that MacOS tried to write zeroes to that region, and far more likely that a TRIM/UNMAP went astray.

That still leaves us with:

- is there a TRIM/UNMAP bug in MacOS? Or do some of the adapters somehow scramble the request so it clears the wrong sectors? Might this depend on the size of the region being cleared at once, and perhaps there's some alignment issue if larger regions that span certain boundaries get split up? (lots of speculation)

- why does MacOS even issue TRIMs/UNMAPs to a drive *after* detecting a corruption or device error? Isn't this extremely risky behavior? I would think the filesystem should go into a read-only state until it undergoes an integrity check and comes out clean, and any repairs being done should only be to written to previously cleared sectors that are known to be empty already. Anything that could possibly be valid data should not be overwritten while the filesystem is in an unhealthy state. And TRIM/UNMAP should be outright disabled at that point until everything checks out as valid again since the state of any mappings can't be trusted.

- how do we avoid corrupting our disks, going forward? For now, I'm checking all my adapters to see which seem safe and which don't and tagging them with colored red/orange/green tape, but I doubt most consumers have the time/patience or knowledge to do this to prevent catastrophic data loss with their external drives in the future. If the fault lies in the adapters, then MacOS really needs some sort of device blacklist. It probably just needs to disable UASP for these adapters and lose the extra performance to avoid corrupting disks. Currently I can't even find a way to force UASP off though, or to forcibly disable TRIM. (yes, I tried "trimforce disable"; is the UASP UNMAP not included as a form of "trim" by this?)

 

[fb77]

Does anyone happen to know if these messages in the system log in any way tell whether a device TRIM/UNMAP is actually being issued, or whether they are just showing the "trim" of higher level bookkeeping in APFS?

2022-10-31 20:25:29.479522-0400 0x2232 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.002075 s (no trims)
2022-10-31 20:25:29.567820-0400 0x2232 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk3 scan took 0.088292 s, trims took 0.086780 s
2022-10-31 20:25:29.567826-0400 0x2232 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3164: disk3 32549952 blocks trimmed in 28 extents (3099 us/trim, 322 trims/s)
2022-10-31 20:25:29.567830-0400 0x2232 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3167: disk3 trim distribution 1:7 2+:4 4+:5 16+:1 64+:0 256+:11
2022-10-31 20:26:27.833880-0400 0x3004 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.001505 s (no trims)
2022-10-31 20:26:28.938598-0400 0x3004 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk3 scan took 1.104709 s, trims took 1.102840 s
2022-10-31 20:26:28.938609-0400 0x3004 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3164: disk3 439352332 blocks trimmed in 127 extents (8683 us/trim, 115 trims/s)
2022-10-31 20:26:28.938614-0400 0x3004 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3167: disk3 trim distribution 1:7 2+:4 4+:5 16+:1 64+:0 256+:110

As far as I can tell, "trimforce disable" doesn't do anything to get rid of these. So either it's having no effect on external USB drives (perhaps because UASP UNMAP is not considered TRIM?) or these messages aren't actually telling whether a device TRIM or UNMAP was issued or not.

 

[fb77]

I can now confirm that those trim messages that show trim counts do NOT show up when using an older USB 2.0 SATA adapter. (which also doesn't cause any filesystem corruption)

The messages that show up instead are ones like the following every time the disk is plugged in and mounted:
2022-11-01 07:33:44.511273-0400 0x6673a Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.004934 s (no trims)
2022-11-01 07:33:49.257875-0400 0x66793 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.005193 s (no trims)
2022-11-01 07:39:14.650951-0400 0x67709 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.005184 s (no trims)
2022-11-01 07:39:25.747366-0400 0x67785 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.079850 s (no trims)
2022-11-01 07:41:39.043031-0400 0x67e80 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.005413 s (no trims)
2022-11-01 07:42:03.210066-0400 0x67fa4 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.077970 s (no trims)
2022-11-01 07:43:00.660717-0400 0x68351 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.004405 s (no trims)
2022-11-01 07:43:18.837811-0400 0x68413 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.077847 s (no trims)
2022-11-01 07:45:35.271865-0400 0x68b3d Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.037514 s (no trims)
2022-11-01 07:45:53.127851-0400 0x68c6f Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.492142 s (no trims)
2022-11-01 07:46:52.751895-0400 0x69102 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.038380 s (no trims)
2022-11-01 07:47:00.524165-0400 0x6918a Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3172: disk3 scan took 0.493337 s (no trims)

Whereas when the same disk is plugged in with a USB3.0 adapter (either ones that do or don't cause the corruption, depending on the adapter chipset), the following immediately shows up after mounting the filesystem:
2022-11-01 07:48:44.382547-0400 0x6971a Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3154: disk3 scan took 1.663866 s, trims took 1.578495 s
2022-11-01 07:48:44.382559-0400 0x6971a Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3164: disk3 488032117 blocks trimmed in 157 extents (10054 us/trim, 99 trims/s)
2022-11-01 07:48:44.382564-0400 0x6971a Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3167: disk3 trim distribution 1:12 2+:11 4+:4 16+:4 64+:0 256+:126

So the problem seems to be related to trimming, and as of Monterey, trimming is apparently now enabled for all external USB drives that can support it via their adapters, which means any USB adapter or external drive with UASP potentially will show this problem if anything goes wrong with trimming. "trimforce disable" doesn't prevent trimming from occurring on these disks. And some USB adapters are not handling the trimming correctly.

I'm not yet sure why this would only occur with drives larger than 2TB. On one of my adapters, that makes some sense, since my Sabrent/JMicron(152d:1561 v2.04) is actually converting the sector size to 4K instead of 512 bytes for the 4TB drive, but not the 2TB drive. So some bug is getting exposed with 4K sectors. It's not clear if that's a bug in MacOS (less likely since the internal drives are all 4K also) or a bug in the adapter, but more likely there's something happening in the adapter. Perhaps it's passing through the UASP UNMAP command without doing the LBA translation for 4K to 512 byte sectors.

On the other failing adapter (Sabrent/VLI(2109:0715 v0.00)) it's using 512 byte sectors still, but fails on the 4TB drive. Not immediately during format, but a brief speed test afterwards writes enough data to cause it to fail. (or perhaps it was already failed after the format anyway-- need to check the moment of failure more carefully)
But trims have occurred after the format, so most likely the corruption started at this point. It always trims again on a remount, so a good disk effectively "goes bad" after mounting using this controller.
Since again there's the 2TB vs 4TB difference, where it just fails on drives larger than 2TB, I'm wondering if it's a bug in the adapter with passing the higher-order bits of the LBA correctly to the TRIM command for the drive.
(either it's getting it wrong when translating UASP UNMAP to SATA TRIM, or it's a UASP SCSI passthrough, and it's not passing those bits through, or the drive itself (MX500 4TB) has some problem when it's passed through that way)

For the record, I'm seeing working trims in the logs and no corruptions so far with the same 4TB SSD with a different Sabrent/Jmicron(152d:0576 v12.14), so it's definitely possible to pass the UASP UNMAP to the drive correctly and have it work. I'm not sure if that case is converting it to a SATA TRIM, or passing it through as a SCSI UNMAP. If anyone has a SATA protocol analyzer and could check, that would be good knowledge to have. Also if anyone has a USB 3.0 protocol analyzer, it would be good to know if the UASP UNMAP looks valid for the case with the 4K sector size, although I suspect it is, and that the adapter or the SSD is what's botching the resulting TRIM/UNMAP.

to summarize: I think the root of this problem is that Monterey has enabled TRIM (via UASP UNMAP) for APFS universally across all external USB drives and adapters that will allow it, and there are bugs getting exposed as a result, which are most likely in the adapters or drives, but they were never exposed before under Big Sur, even if "trimforce enable" was turned on before. Unfortunately people are finding this out the hard way when they upgrade and an adapter or external disk that seemed to work just fine before ends up corrupted and they completely lose a 4TB or larger filesystem.

 

[frou]

My USB drive (WD 4TB HDD) has taken a full 5 minutes to mount, in every version of Monterey I can remember. Apart from that, it seems to be working fine.

 

[fb77]

My USB drive (WD 4TB HDD) has taken a full 5 minutes to mount, in every version of Monterey I can remember. Apart from that, it seems to be working fine.

I'm not sure why it would be so slow, but it makes sense that you're not seeing the issue discussed here, since it seems to be specifically an SSD issue, and only for drives larger than 2TB. Although if it's truly a TRIM/UNMAP issue, it *could* theoretically affect HDDs also if they happen to have TRIM/UNMAP support, which AFAIK is just something some (all?) SMR drives have. Do you have a way of checking if your HDD is SMR? Or if it has TRIM/UNMAP support? If it does have that, I would be very careful about making sure everything is backed up, because it could still be at risk.

 

[fb77]

One additional note: I've found that running a write-intensive workload like the Blackmagic Speedtest doesn't seem to actually be causing the corruption by itself. It either causes an already-corrupted APFS to get detected quickly, or it generates a lot of content that causes the next trim to show the problem, but I don't see the next trim actually occurring (at least not under this workload) until the next time the filesystem is mounted. However, I've seen a long run lead to a an IOUSB controller reset, which can then lead to a re-mount if it comes back. (or after an unplug/re-plug) and then the next trim can cause the corruption. (or at least the next mount can lead to the corruption, and a trim occurs, so I'm assuming it's the trim that's causing it, since that still seems to be the common factor when it occurs)

 

[macskiman]

One additional note: I've found that running a write-intensive workload like the Blackmagic Speedtest doesn't seem to actually be causing the corruption by itself.

fb77: Your understanding and speculation regarding this issue are amazing. I would hope Apple's programmers have this much knowledge or understanding of the issue, as well as the concern to find a solution.

I would like to think Apple would would be interested in what you are pointing out. Customers trusting Apple and losing data is unacceptable!

I wonder if any Apple's programmers follow discussion forums.

Thanks for all your time and input!

 

[ahnz]

it’s unfortunate I also got this problem
I think it would be helpful if everyone share the adapter brand that’s not affected by this problem.
I already lost hundred gigs of data because of corrupted external ssd, fortunately it’s still covered by guarantee.
I don’t want to lose my data again.

I use 1 TB m.2 ssd from Team with orico M2PJM-C3 (RTL9210B adapter)
It’s working fine in big sur but got corrupted in monterrey.

Is anyone have tried asus strix ssd enclosure? is it safe in monterrey/ventura?

 

[EssentialGadget]

One additional note: I've found that running a write-intensive workload like the Blackmagic Speedtest doesn't seem to actually be causing the corruption by itself. It either causes an already-corrupted APFS to get detected quickly, or it generates a lot of content that causes the next trim to show the problem, but I don't see the next trim actually occurring (at least not under this workload) until the next time the filesystem is mounted. However, I've seen a long run lead to a an IOUSB controller reset, which can then lead to a re-mount if it comes back. (or after an unplug/re-plug) and then the next trim can cause the corruption. (or at least the next mount can lead to the corruption, and a trim occurs, so I'm assuming it's the trim that's causing it, since that still seems to be the common factor when it occurs)

Please try my fix and let me know if it works for you.

https://forums.macrumors.com/threads/does-monterey-have-a-bug-with-mounting-external-drives-images.2331283/post-31535361

 

[Alvin777]

Hello, try this pattern for those still having problems mounting images (like .dmg) and external drives of all types (USB and/or Thunderbolt). I heard this software bug (coz' again, if you have a dual boot of High Sierra, it all mounts without problems) is in macOC Ventura too, I hope not (coz' I'm about to upgrade to it but Time Machine and backup are a great friends, just in case):

1. Download the app FastDMG (or similar apps), drag an image, a .dmg onto its icon on the Dock for the app to force mount the .dmg

2. replug the external drive that won't mount, try different patterns (the usual cycle patter: turn on external drive and then plug data cable/power cord if it's not a flashdrive type or it's all plugged in and then turn the external drive On)

Merry Christmas still (a 12-day season, ending in early January) & a happy new year, 2023 is totally ours, we much claim it.

 

[qazws123]

I had the same issue, 2 x external WD HDD's connected via USB 3 hub not mounting on MBP 2015 running Monterey 12.6.

My problem completely resolved by turning Bluetooth OFF. An easy fix if you can live without BT while doing external HDD tasks, which I can fortunately.

 

[Attonine]

Run into this issue today. 15" 2017 MBP. )OSX 13.2. About 3 months the ago I thought external HDD had just died. Finally got round to buying 2 new ones today, and neither mounts. CMD-R restart and I can see both the drives in disc utility and can mount them. System info - I can see both the HDDs attached to the relative USB ports. However, Disc Utility etc just cannot see the HDDs One is LaCie rugged, the other Tech ATD.

Done all fixes I can find from various forums NVRAM, SCM, Checked preferences for externals to show on desktop etc etc. At a loss especially as CMD-R restart shows docs mounted and Im able to erase, first aid etc......Finally, there is an odd behaviour, lights on the drives, when attached, stay constant, no flashing as is usual when you attach an HDD, also can't hear any searching in HDDs, just a very constant hum from a constant spin - not normal

 

[qazws123]

Try disconnecting Bluetooth >turn off machine >connect external HDD’s >start up machine. This worked for me, let me know if it works for you. You just need to work around not using Bluetooth while HDD’s connected.

 

[qazws123]

Run into this issue today. 15" 2017 MBP. )OSX 13.2. About 3 months the ago I thought external HDD had just died. Finally got round to buying 2 new ones today, and neither mounts. CMD-R restart and I can see both the drives in disc utility and can mount them. System info - I can see both the HDDs attached to the relative USB ports. However, Disc Utility etc just cannot see the HDDs One is LaCie rugged, the other Tech ATD.

Done all fixes I can find from various forums NVRAM, SCM, Checked preferences for externals to show on desktop etc etc. At a loss especially as CMD-R restart shows docs mounted and Im able to erase, first aid etc......Finally, there is an odd behaviour, lights on the drives, when attached, stay constant, no flashing as is usual when you attach an HDD, also can't hear any searching in HDDs, just a very constant hum from a constant spin - not normal

Run into this issue today. 15" 2017 MBP. )OSX 13.2. About 3 months the ago I thought external HDD had just died. Finally got round to buying 2 new ones today, and neither mounts. CMD-R restart and I can see both the drives in disc utility and can mount them. System info - I can see both the HDDs attached to the relative USB ports. However, Disc Utility etc just cannot see the HDDs One is LaCie rugged, the other Tech ATD.

Done all fixes I can find from various forums NVRAM, SCM, Checked preferences for externals to show on desktop etc etc. At a loss especially as CMD-R restart shows docs mounted and Im able to erase, first aid etc......Finally, there is an odd behaviour, lights on the drives, when attached, stay constant, no flashing as is usual when you attach an HDD, also can't hear any searching in HDDs, just a very constant hum from a constant spin - not normal

Try disconnecting Bluetooth >turn off machine >connect external HDD’s >start up machine. This worked for me, let me know if it works for you. You just need to work around not using Bluetooth while HDD’s connected.

 

[Attonine]

Try disconnecting Bluetooth >turn off machine >connect external HDD’s >start up machine. This worked for me, let me know if it works for you. You just need to work around not using Bluetooth while HDD’s connected.

Doesn’t do anything for me. Will try clean install today - totally erase OS and start from zero again. Dropped machine off with someone this morning.
I can’t see how this can be anything other than a software issue as the drives all show up on CMD-R restart > disc Utility, and in system info.

 

[EssentialGadget]

Doesn’t do anything for me. Will try clean install today - totally erase OS and start from zero again. Dropped machine off with someone this morning.
I can’t see how this can be anything other than a software issue as the drives all show up on CMD-R restart > disc Utility, and in system info.

Please try my fix and let me know if it works for you.
https://forums.macrumors.com/thread...-external-drives-images.2331283/post-31535361

 

[Attonine]

Please try my fix and let me know if it works for you.
https://forums.macrumors.com/thread...-external-drives-images.2331283/post-31535361

Too late. It was clear the issue was software, not hardware, as the MBP could see the drives and manipulate them if I did cmd-r restart and chose disc utility. As I had already tried a reinstall and the issue persisted, I contacted an Apple tech who could do a clean install for me (was easier to get someone else to do it at this time). before he did this he poked around and identified several corruptions on the system, so clean install was prescribed by him too. He did it né bingo, all drives mount as they should.

 

[saudor]

I'm not sure why it would be so slow, but it makes sense that you're not seeing the issue discussed here, since it seems to be specifically an SSD issue, and only for drives larger than 2TB.

A similar thing happens with HDDs and it's related to the 4K vs 512 sector sizes on some of these enclosures.

Situation 1: You can format a max 2TB HD in the enclosure and it will work fine when removed from the enclosure and connected internally via SATA. A drive formatted on a SATA connection remains readable in the enclosure

Situation 2: Format a >2TB in the enclosure and it won't be readable via a direct SATA connection and show up as 16TB RAW partition(For a 4TB drive). You can reformat it but it won't work again once you put it back in the enclosure.

Going back to the SSD, i think your speculation is right. With certain UASP-enabled enclosures, TRIM/UNMAP is probably erasing the wrong sectors as the enclosure messes up the 4K sector translation.

My enclosure with the ASMedia ASM1153E controller chip is OK but the Jmicron (used in the Sabrent) cant handle it.

 

[Uploading]

Hi all, I just recently made the jump from High Sierra to Monterey(I hate it, it's garbage), I did a clean install and migrated my stuff over manually but in the process I ran into this dreaded problem where my external SSD would take an eternity to mount and unmount. I managed to backup all my stuff on a mechanical drive. Anyhow, it doesn't look like this external ssd problem has been fixed. How are people dealing with this problem? Installing Big Sur?

 

[EssentialGadget]

Hi all, I just recently made the jump from High Sierra to Monterey(I hate it, it's garbage), I did a clean install and migrated my stuff over manually but in the process I ran into this dreaded problem where my external SSD would take an eternity to mount and unmount. I managed to backup all my stuff on a mechanical drive. Anyhow, it doesn't look like this external ssd problem has been fixed. How are people dealing with this problem? Installing Big Sur?

https://forums.macrumors.com/threads/does-monterey-have-a-bug-with-mounting-external-drives-images.2331283/page-5?post=31535361#post-31535361

 

[Uploading]

https://forums.macrumors.com/threads/does-monterey-have-a-bug-with-mounting-external-drives-images.2331283/page-5?post=31535361#post-31535361

All my other external SSD worked just fine prior to installing Monterey. I can mount and boot my external SSD from recovery without any problems. The drives take an eternity to mount/unmount in Monterey. I'm going to install Big Sur.