I know the SN750 is the most recommended NVMe SSD, but has anyone tried the newer model, the
SN770?
According to t
his chart, it uses a WD proprietary controller, not one of the problematic Phison controllers. It's also priced similarly to the SN750 and seems to have better availability. My motherboard (ASUS Prime Z490-A) doesn't support PCIe 4.0, so I wouldn't be able to get the full advertised speeds, but if the price drops on the 2TB model, I might consider getting it.
After a year of paying attention to this issue, I've never seen an explanation that claimed to understand why some drives are problematic and others aren't, and no one here is doing any research. The idea that certain controllers are a problem in and of themselves is a conjecture with no clear evidence.
Publishing a list is not research. To the extent that know-how is codified into certain well-read posts, it ages poorly, and is never backed up by any reference to deep understanding.
It comes down to some drives are known to not work well, and others are known to not have gone wrong yet.
So you will have to try.
The catch is I have personally the startup Trim malaise arrive across macOS releases, and also seen a 980 Pro go from seemingly fine wrt Trim to problematic with a firmware update. So even if you try and it works, this could change.
With hackintosh, the community however strong is not in a technical position to actually make things work, and never will be, because it lacks access to key engineering information to understand and advance approaches.
So a question such as "can XYZ drive work cause it's got a different controller" is not meaningful. It's at the level of
should I sacrifice a chicken on Tuesday to ensure the gods will look after my hack?
—Don't be tempted to overindulge lore such as for compatible wifi/BT modules per my point: the case of a component with known support in macOS panning out is an edge case. There's never been any such for NVMe drives (plus I have seen a SATA disk from Apple that doesn't play right with sn external enclosure; it takes writes without error and throws them away). When considering clever workarounds, such as adapting Intel AX, or TB, the story always comes with caveats on functionality and later surprises.
At this point, with each release of macOS / 3rd party hack etc, it's half something-given, half something-taken-away. Something that doesn't get mentioned is the risk surface associated with the whole approach to hackintosh. Is my system burning half-a-core on kernel_task because it's been co-opted into a mining farm, or pumping spam? Anything can go on beneath the covers. After reading 10,000 posts I've ever seen one that says "after reviewing the code for kext XYZ...". Pls do not take this as sowing doubt, take it as appropriate concern.
The cataloging approach to gear lore used on these forums is based on a not-yet-known-to-fail precedent. That's powerful for cobbling together a running system, but it should never be confused with understanding.
Such approach can eventually lead to a ghetto.
My nagging thought is that the energy here needs to find a way over to Linux: help make it more mac-like in whatever way you think that's important.
Or better yet, work on something really new that puts maclike to dustbin.
Blah blah