Choosing a Compatible NVMe SSD for your macOS Boot Drive

[c-o-pr]

I would really like to understand better this topic. I'm a content creator and rely on my 980 pro as a data disk. After more than one year and about 65% drive space used it still reads and writes with proper speed. I would just like to know if trim is working or not... I mean if the drive has trim problems sure they're more visible as a startup drive...but still they would cause problems as a data drive as well in the long term

I don't think this situation will ever be understood. We lack the information and support needed to make sense of it.

Plus there's a swamp of bad information about TRIM and cargo-cult approaches to working with it.

I have used a 980 Pro as both a Mac boot and data drive for a couple years. My firsthand experience is misbehavior directly interfering with my work. And trying to work around it has been a huge PITA. But I have never lost data. (I have suffered multiple total drive failure with another brand under Big Sur.)

For a few months, 980 Pro ran well under Monterey. In early 2022, I did a firmware update from Samsung and that's when TRIM stalls became a problem for me. The SetApfsTrimTimeout quirk helped somewhat by speeding up boots, but during macOS updates and APFS snapshot maintenance, the delays became a huge nuisance lasting 15 minutes and hanging everything.

When I used 980 Pro as a USB attached drive under Monterey, it would become unstable and hang the Finder. This pathology seems to have been fixed since Ventura. So I have since relegated the drive as a second backup.

On top of these headaches, macOS has been a bug-ridden monster these last few years, which hackintosh makes even worse!

Here's what we're up against: It's impossible to track effects when so much keeps changing...
- Constant macOS major and minor updates,
- drive firmware updates,
- board firmware updates,
- OpenCore updates,
- drive enclosure firmware updates,
- OC configuration e.g., USB, NVMefix, quirks, etc.

It's a madhouse!

Then there's concern for drive controller generations and versions, manufacturers changing controllers within specific models, Apple constantly tweaking the storage scheme and filesystem.

And lastly: Trim is one of the most misunderstood and mixed up features ever perpetrated on PC users!

If you have 980 working as a data drive, don't change anything.

As to Trim working or not in the case of the 980: the one and only value of Trim is as a hint from the OS to the drive to improve wear leveling, with an implication on device durability over the long haul.

In my direct experience, macOS Trim cycles on 980 Pro count against device wear according to Samsung Magician, so if there's a way to turn NVMe trim off under macOS I would because not only is it wasting my time it's wearing out the drive faster!

 

[trs96]

If you have 980 working as a data drive, don't change anything.

The Samsung drives like the 980 Pro work great with Windows when optiimized by their Magician software. So another option is to simply use that with Windows and get a low cost WD SN570 1 or 2TB drive to use as a macOS data drive.

 

[theSov]

Thanks for this thread.

The time has finally come to replace the Samsung 970 EVO for my 2018 hack. I've been making do with the drive: tolerating the lethargic post-Monterey boot times, and over the past year or so, enduring periodic volume hash mismatch errors and some other seemingly random system issues such as applications not launching, losing Time Machine backup settings, and difficulty applying system updates.

Appreciate your detailed information, insights, and recommendations.

 

[brousseau6933]

Thanks for this thread.

The time has finally come to replace the Samsung 970 EVO for my 2018 hack. I've been making do with the drive: tolerating the lethargic post-Monterey boot times, and over the past year or so, enduring periodic volume hash mismatch errors and some other seemingly random system issues such as applications not launching, losing Time Machine backup settings, and difficulty applying system updates.

Appreciate your detailed information, insights, and recommendations.

WD NVME drives. SN850, SN850x, SN770 and even, WD Blue SN570. If your hack is PCIe 3 Gen, you won’t see a big difference between all of those. They will all saturate the PCIe 3 bus. Me, I’ve chosen two SN770’s for my two main Coffee Lake Hackintoshes. Flawless…

 

[theSov]

Hash errors are a sure sign of drive returning wrong data, which implies everything on the drive is suspect to corruption. This is an under-discussed serious problem with storage.

Agreed.

WD NVME drives. SN850, SN850x, SN770 and even, WD Blue SN570. If your hack is PCIe 3 Gen, you won’t see a big difference between all of those. They will all saturate the PCIe 3 bus. Me, I’ve chosen two SN770’s for my two main Coffee Lake Hackintoshes. Flawless…

I'm with ya... got a SN770 on order.

 

[c-o-pr]

WD NVME drives. SN850, SN850x, SN770 and even, WD Blue SN570. If your hack is PCIe 3 Gen, you won’t see a big difference between all of those. They will all saturate the PCIe 3 bus. Me, I’ve chosen two SN770’s for my two main Coffee Lake Hackintoshes. Flawless…

Having directly compared PC3 and PCI4 SSD in one build, I saw the only difference was benchmarks.

I have not seen an ordinary use-case in which a PCI4 system drive makes any difference. If you don't have to wait with PCI4 drive, you won't have to wait with PCI3. If you have to wait with PCI3, you will wait with PCI4.

However there may be meaningful advantages to PCI4 drives simply because they trend towards newer more expensive controllers.

As to the suitability and stability of any line of drives on hack. The best way to go is consensus on least issues, and WD have been solid for last 3 years.

But this might change at any moment.

Be on lookout for creeping assurances models and overt buy recommendations based on history of previous models.

Any drive you choose is an experiment for you, so go carefully.

 

[brousseau6933]

Having directly compared PC3 and PCI4 SSD in one build, I saw the only difference was benchmarks.

I have not seen an ordinary use-case in which a PCI4 system drive makes any difference. If you don't have to wait with PCI4 drive, you won't have to wait with PCI3. If you have to wait with PCI3, you will wait with PCI4.

However there may be meaningful advantages to PCI4 drives simply because they trend towards newer more expensive controllers.

As to the suitability and stability of any line of drives on hack. The best way to go is consensus on least issues, and WD have been solid for last 3 years.

But this might change at any moment.

Be on lookout for creeping assurances models and overt buy recommendations based on history of previous models.

Any drive you choose is an experiment for you, so go carefully.

You are right. In fact, I didn’t « see » any improvements since I converted my two Coffee Lake from SATA SSD’s to NVMe’s as OS drives in real life use, not even really in boot times… In benchmarks only as you said. Mind you, I’m not transferring big files all day long, just normal computer duties.

In my personal case, audio reading/writing is still done on mechanical SATA drive (plenty fast for the job) and sample (DAW) reading on an external Samsung T7 USB 3.1 Gen 2 (10 gbps).

Maybe (?) it would be a little faster reading samples from a faster NVMe (T7 has a NVMe blade inside) but my readings on audio forums tells me that the benefit in speed would be almost unnoticeable. Speaking about loading big sample libraries in Kontakt BTW.

 

[GIZLIN]

I have WD 750SE drive. My computer has kernel panics and crashes every now and then. I guess, I know now why that is the case ;/

Here are few lines from the latest crash report I had today:
panic(cpu 0 caller 0xffffff801ff8d676): nvme: "3rd party NVMe controller. Command timeout. Write. fBuiltIn=1 MODEL=WD_BLACK SN750 SE 1TB FW=711130WD CSTS=0x1 US[1]=0x0 US[0]=0x4d VID=0x15b7 DID=0x501e CRITICAL_WARNING=0x0.\n" @IONVMeController.cpp:6151
Panicked task 0xffffff9532bf7208: 219 threads: pid 0: kernel_task


The system crashes whenever I rush through pics or PDFs quickly with a QuickLook.

 

[dasboot5]

So here is a compatibility question for NVMe drives to be placed in the first slot (m.2_0) either the highest slot on MATX or ATX boards or the top of the board slot, on an ITX board, using a Z590 chipset.

If you use a 10th gen processor and the latest BIOS, usually this slot is TOTALY disabled from usage. However, if you use an 11th processor, the question is, under normal conditions, the slot would be unlocked for use, as this is an Intel rule or (architectural ELECTRONIC design relating to Gen 4 PCIe functionality). But, since the 11th gen processor has to be spoofed to be seen as 10th gen by the Mac OS to work, as the Intel/Arm switchover took place at 10th Gen, does the slot still function even with the spoof, as the interaction between the processor and the slot happens at Bios level before the OS takes over? Or does the spoofing then disable it, using Ventura, as the spoof would need to be present in the installer flash as well NOT ALLOWING THE DISK TO BE SEEN IN DISK UTILITY?

For all that still may have questions in this regard, The 11-gen processor, immediately unlocks the disabled slot in the bios, and the recommended CPU spoof to the 10th-gen does not interact with the PCIe lane that is unlocked by the 11th-gen feature. IE there is no real reason to use a 10-gen processor in my opinion for Z490 or Z590 chipset boards as the feature set is wider on 11th-gen, the price difference at this point, in time, is insignificant, and a bios upgrade will allow the refresh processor to work with all slots functioning, using spoofing.

 

[c-o-pr]

One of the questions that can come up for anyone is: "How do I know if my system is failing because of an incompatible SSD?"

A post titled "Choosing a compatible SSD" makes it seem like the nature of compatibility is understood, but where is the information to support that?

The thing's I believe about SSD incompatibility from my own experience, Dortania, and these forums are as follows, in order of my encounters since early 2021:

• macOS Big Sur could kill Sabrent Rocket4 (My own experience). It killed 2.

• some NVMe SSDs are reported as difficult to use with hackintosh for various reasons, because of stalls and in some cases death. (Dortania). This dates back several years and was described as pertaining to certain generations of Phison controller, but the report was anecdotal.

• Stalls were determined to be related to macOS Trim cycles, usually at boot (Dortania Anti-hack Buyers Guide). A quirk SetApfsTrimTimeout later appeared in OC to work around these stalls. With Monterey the utility of this quirk was reduced from a selectable timeout to a single timeout value of 0 and it doesn't always work. (Dortania and my own experience). The backstory for the conditions leading to this quirk and its evolving limits are unclear and incomplete according to my reading of the OC documentation and comments from Dortania contribs.

• My Samsung 980 Pro developed a problem with Trim stalls at point-in-time firmware update. This could be seen at boot with a long hang around boot messages for the Apfs space management and intense boot drive activity for the duration of the stall. This stall also occurs when deleting APFS snapshots (My own experience). This is also the case in Ventura.

• Samsung problems started being widely mentioned to suffer from Trim stalls around time of Ventura release (tonymacx86 forums) which would correlate with widening adoption of Monterey. Hack users tend to hold back on macOS upgrades. But in my case the 980 Pro Trim problem started the moment after installation of a drive firmware update.

I have looked for but never seen a technical explanation on how macOS handles Trim, nor any details on why certain drives get befuddled. There are only anecdotes that certain drive controllers are hazards, but even these reports are vague.

My conclusion is there's no criteria for "compatible" NVMe, because there's no technical explanation for why drives are incompatible.

On one hand NVMe is about as standardized as any PC subsystem (it's a long term Intel evolution of ATA drive attachment) while Apple has an enormous reputation building systems based on IA PC as well as contributing to major industry-changing PC architecture features from the early days of personal computing, through all modern mobile, desktop and HEDT PC configs, as well as becoming a trillion $ company designing their own kit... So the idea that Apple doesn't really understand NVMe or that Apple sees NVMe in some profoundly different way than Intel makes no sense.

But the point that Apple has recently veered away from commodities PC NVMe form-factors and has not released an Intel Mac for years means hack users should expect that edge applications edge cases will expand.

But OTOH all hack NVMe bruhaha I've seen is directly focused on one feature: Trim. It's a bad idea from the get-go, it's function never been truly standardized, there's no common usage model, it's application is an administrative config detail, device makers have a history of doing it badly, and without a careful study of how it's applied, it's not clear it's even useful for modern drives. To say this another way: it's a feature everyone thinks they should have but no one knows exactly why. IMO the existence of Trim is the problem.

So I suggest that "choosing a compatible" NVMe be reframed as "avoiding an incompatible" NVMe where incompatible todays can be understood in only one dimension: Does macOS Trim not play properly.

If there are other specific modes of incompatibility, let's talk about those details.

---

P.S. I need go back and re-read the OP for this thread to see if I'm overlooking details that @trs96 has studiosly provided.

I think OP focus on Apple departure from NVMe form-factor is a very interesting topic, with serious implications for hack, but I think it's also a red herring re hack drive incompatibility, because macOS still has deep roots in Intel PC.

---

P.P.S. Some backstory on my Rocket4 failures. One lasted about a month and the other lasted about a week. The drives seized and became useless.

My focus at the time was on my build, not on drive troubleshooting and I didn't know what I was dealing with when first drive spontaneously croaked. I returned it for a replacement. With the second Rocket4, I stressed it and tracked thermals. It would get very hot. By pushing it would go over 90C, then seize. A couple times it recovered then it became completely extremely slow to point of not completing IO and would get very hot as soon as it was powered on in a Sabrent USB enclosure — too hot to touch the enclosure.

My thinking developed towards the idea of overheating issue related to Spotlight indexing. I had previously seen that SSD upgrade to Macbooks would cause fans to race and realized that macOS Spotlight energy use was checked by slow spinner drive IO. Upgrading to SSD unleashed mdworker processes and maxed CPU until indexing completes. This is a peculiar upgrade edge case which I could test by deleting a spotlight index via mdutil.

So in order to stress Rocket4 I would delete the Spotlight index and run find(1) dumped into /dev/null then watch the Rocket temps soar with iStatMenus.

At that time I was not aware that macOS may be issuing Trim at boot. Because I am running a 2TB drive that is half-full with a million user files, plus half empty means 1TB needs to be trimmed, the perfect storm is handing the NVMe a large amount of async Trim (Discard) commands at boot, with Spotlight workers on 10 overclocked cores going full tilt boogie, and also pounding drive with random IOs by fstats from find. Add APFS and this all adds up to a uniquely Mac overload that drive makers who focus on Windows or Linux have never encountered. Sabrent is uniquely focused on bragging rights for PC gaming, so they may have set the stage by tuning for max IOs over safety and qualified it under assumptions about Windows use cases that would never over-exercise the device. A few months after my experience, Sabrent intruduced offering enormous expensive add-on heat-sinks.

But the problem might not be overheating, per se. The problem might be bugs in the controller that make it go wonky, where overheating is just a side-effect.