I went back through this thread and the answer is the Apacer drives are incompatible due to Trim.
Use a different drive.
As this is annoying, you may hunger for an explanation, so below I'll do my best to provide something like the idea of a root cause:
What we are seeing in macOS since Monterey is that large areas of free space are trimmed (so to speak) at every boot, and that some drives take the commands to mean literally refresh every free block, which amounts to having to wait for a large drive to be completely re-written at every boot. Other drives aren't so literal.
This situation occurs because what Apple thinks Trim commands should do disagrees with what the drive actually does.
It's pointless to argue which is correct, they just disagree.
The solution is to use a not-incompatible drive.
Drives are known to go wrong at edge cases and completely fail, so going with the herd makes sense for peace of mind. The herd says use WD.
If you are curious about underlying factors contributing to of this unfortunately state of affairs, here are some thoughts:
- According to the NVMe spec, Trim behavior is open-ended: The drive is free to handle Trim commands in its own way. The internal effect of Trim ranges from doing nothing at all to forcibly refreshing every affected page. The problem at hand is a mismatch between what Apple code expects a drive to do and what it actually does. Some drives refresh every affected page.
- At its most fundamental level, Trim of a form of write. It affects the refresh of flash pages which store groups of logical blocks (the blocks used by the filesystem).
- Historically freeing up logical blocks is not part of a drive workload so supporting Trim is additional IO work.
- Trim is typically applied in two ways depending on the filesystem and policy of the system: it is applied on the fly during normal system operation, where Trim competes with other drive IO, or it is applied in batches on a schedule to avoid interference with other work. Apple uses a boot schedule since Monterey. It also may Trim all free space during system update. I have reason to believe that previous to Monterey Trim was only applied by Disk Utility.
- The semantics of Trim commands regarding the state of logical blocks upon Trim completion happens to overlap with concerns for data privacy / security; IOW what state should Trimmed blocks have upon completion? There are different ways of looking at this, e.g., should the underlying flash page actually be cleared or is it sufficient that it is set aside?
- Trimming is applied at the level of logical blocks, but at the level of flash it implies a refresh of at least an entire flash page, which may include other logical block unrelated to the logical blocks specified by the command, so remapping or copying may be required to refresh. This is expensive.
- Reading the specs from ATA to NVMe, the significance of the features supporting Trim have changed emphasis away from wear mgmt towards data security, e.g. semantics along the lines of tools like shred.
- Consumer drives tend to be tailored for a Windows Trim regime.
- Linux tends to adapt to PC HW, so the hazard of different drives Trim will tended to be accounted for by the OS, whereas Apple makes all its own storage to its own standards, with a tiny aftermarket compared to PC, so compatibility is more problematic.
To summarize: the history if Trim dates from the 80s with flash managed by OS code on a weak CPU, to today where every drive contains a dedicated processor 1000x more powerful than a 1980s supercomputer.
The specs have always been open ended about what Trim should do.
Today, the logic for flash mgmt is proprietary juju that belongs to the drive maker.
Apple rolls its own storage in its own form-factors, while socketed NVMe is a purely PC feature.
All Apple designs that use socketed NVMe are now legacy.
