Contribute
Register

General NVMe Drive Problems (Fatal)

More thought:

If you are not using NVMeFix, try it. If you are using it, try disabling it!

Can you boot Windows and run Samsung Magician? If so, check for firmware.

Also look at SMART dump any way you can... Is Media Errors > 0? That might be bad for various reasons. It might just cause an I/O stall leading to a read timeout. Add in possible Monterey policy changes on NVMe health and who knows?
Under Big Sur, I encountered failed clone from a fresh new 980 Pro which was actively running on my system. I was using APFS copier (CCC Legacy Bootable Backup Asst) which failed to complete with no clear error message and no OS drive warning. I checked SMART and media errors were recorded. I used regular CCC backup and it reported unable to copy a file, which was in fact an known previously good image file which is now corrupt. But no read errors. I returned to a previous backup and wiped the 980 with ddrescue /dev/zero then re-read the whole drive the same way. No errors but reads slowed way down in middle. As it was entirely readable I APFS cloned my build back to 980 and it seemed OK but SMART media errors climbed, so I RMA'd to Samsung and received another which I am running now.

My point is that I didn't get any warning sign from OS, just failed copy, corrupt data and slow performance.

So its look at SMART and if it shows errors, that could be cause of strange behavior

HTH
 
I have two NVME m.2 drives and both are in the NOT working list
Samsung SSD 970 EVO 250GB (Big Sur 11.6.1 (20G224))
Seagate BarraCuda Q5 ZP500CV30001 500GB (UBUNTO 20.04 LTS + NTFS DATA Partition) Phison E12 controller

Also I am not going to spend extra money for a new NVME drive. So I have gone back to Big Sur after giving a try to Monterey. I had big problems with Bluetooth on my DW1560 card and of course the slow boot time.

I am on opencore 0.7.5 and my SetApfsTrimTimeout is -1

My Big Sur shows me the login screen in around 15 seconds from clicking on it in opencore.

So should I change the SetApfsTrimTimeout value?

Some thoughts:
Slowly Apple is killing the Hackintosh advantage
Making it more complex with each new Operating System
No DRM
No Airplay 2 for video streaming (screen mirror works)
Brief experience in Monterey streaming to it from iPhone/iPad doesn't work (one of the new features)
More restrictions on compatible hardwares
The BIGGEST advantage Price, try making a Hackintosh like a M1 compatible MacMini.
Time - in a year or so total migration to ARM base CPU.
So enjoy Hackintoshing till we can!
 
I recently purchased a Samsung 980 Pro NVMe 1TB not knowing about this issue. Sounds like I shouldn’t use it as a boot device for Big Sur or Monterey.

Would this trim issue exist if I use it as a storage drive? Would APFS or HFS+ formatting make a difference?

-Edit- I’m thinking the problem would still exist wether it’s a boot drive or storage drive. You just happen to see it with longer boot times if it‘s the startup drive. So… we shouldn’t use the Samsung NVMe SSD’s at all, correct?
 
Last edited:
The issue exist with any use under OS X. A data drive which has less activity than the boot drive may be less severely affected—but a scratch drive would die even faster.
Short of changing drives, staying with Big Sur or setting the TRIM timeout to the maximal value seem to be the best mitigating strategies.
 
I recently purchased a Samsung 980 Pro NVMe 1TB not knowing about this issue. Sounds like I shouldn’t use it as a boot device for Big Sur or Monterey.

Would this trim issue exist if I use it as a storage drive? Would APFS or HFS+ formatting make a difference?

-Edit- I’m thinking the problem would still exist wether it’s a boot drive or storage drive. You just happen to see it with longer boot times if it‘s the startup drive. So… we shouldn’t use the Samsung NVMe SSD’s at all, correct?
I'm using a new 980 2T under Big Sur previously and updated to Monterey last week. I have not yet seen boot delays re Trim. But I try to avoid booting :/

I tried a more searching on this matter, and found reports on other forums (eg stackexchange) about SSD Trim boot delays dating back before Big Sur. Samsung 970 is the common trait. It's discussed in terms of APFS, not OS version, but as one implies the other, no surprise it's coming to a head over a version.

There's less discussion about this topic on MacRumors 'Unsupported' threads than I expected, but I didn't peruse.

There were reports several months ago that chip sourcing problems lead Samsung and WD to change model details that affect performance, which they did without rebranding, annoying customers. I don't see any correlation between these reports and that news...

...which brings my thinking to the point that all of this is anecdotal with very small sample sizes and little follow-up.

For example:
• What happens when a long Trim pass completes. On the next boot is it speedier?
• Is the degree of Trim new under monterey? Does macOS now issue DISCARD for all free blocks at every boot, when before it only did so only during or after a fsck?
• Apple built a Trim timeout into the storage manager, so doesn't that imply that the Trim workload has known edge-cases for Apple gear? (Maybe only used in dev idk)
• Free-block churn is workload specific, so some users may see more of a problem.
• The whole design of Trim is based on premise of pay now for a performance remediation later. Repeating myself: Trim is a form of write (DISCARD device command). Well the piper has to be paid! So while a few minutes at boot may or may not be a big deal, what's at work is not necessarily a bug or error, but an operational edge case over specific devices and workloads.
• Of course SSD vendors may have problematic response to some patterns of DISCARD or the mixing the command with other commands. (This all adds up to show why Trim is a stupid idea)

Then there's the concern that certain SSDs can be killed by macOS. So this far seems to be a very rare condition, which begs all the above questions. But we have to note that nothing about the hackintosh experience is designed to measure, understand or respond to wide-spread design issues because the whole scene is powerless to see inside the system design, much less make design adjustments. Everything we know and every solution is anecdotal.

I think this SSD pathos is worth special attention. It stands out as a "compatibility" zone where hackintosh users who have been surfing the long wave of Apple-on-IAPC guts are finding that wave collapsing — over a reef for some — as Macs can no longer be thought of as being built from the same stuff as PCs. This is evident in the last 5 years of both storage trends, where Apple NVMe has tended to be custom form-factor in 2015 era macbooks then soldered in after that, and GPU trends.

Hack users want to consider where they will end up. This is the end of the line. You can buy parts today that will be serviceable for about the next 3-5 years for none-Apple juju apps.

The best refinements of Apple HW are not hackintoshable: improved laptop mics/sound, displays, energy mgmt, evolving continuity features. That AppleSi is killing on raw performance reveals how Intel is lacking interest in curation of its own architecture.

At the same time these large evolutionary progressions are occurring, to me surprisingly little advancement of the medium is occurring. The only compelling Apple juju in recent memory is this new neural-net image OCR that lets me copy/paste text from images, and that's not very important. (I am not excited by the promise of augmented reality because I enjoy the state of not knowing what I'm seeing.) All social media juju and "helpful" stuff like image face recognition is to me like flying toasters: sometimes I'm amused that my phone shows me an aesthetically pleasing shot from my photo history, but it's meaningless in personal way the same way the color of my car is meaningless but personal. It's not important in a world that's torn asunder and catching on fire.

I very much don't like the idea of parental controls in general, and especially don't want Apple being the parent, using my PC to thought-police what they consider broad social issues. I would feel differently if Apple execs took the stage to express their dismay that their technology is causing a collapse of the commonwealth and they have no other ideas but feeding customers CandyCrush and treacly self reminiscences to keep up the consumer hype.

I came across an Apple genius ad campaign photo of the famous late physicist Richard Feynman, wearing a Danny Hillis Connection Machine t-shirt, and I thought my god, Apple was shameless then. But at that time they still could make me think they had some concern for the commonwealth. Now it's clear beyond any doubt that 2024 will be as bad as 1984 and Apple always wanted to be the goggly-eyed overlord. Their promise to be a benign overlord is no comfort to me at all.

As I said, hackintosh users will need to take stock of these trends, both long-term and near, and wonder where we want to end up?

Let the GC demon in your NVMe SSD be a little shamanic instigator to the asking of such questions.
 
For the sake of clarification, without delving into nitty-gritty details:
  • The TRIM issue is evident only with a range of NVMe drives. Your 980 PRO may (or may not) be among them. The SSD Hall of Fame at Dortania's bugtracker keeps a modest list of drives known to be affected, and those known to be safe. The 980 PRO isn't listed at all (as I write this), however, I have read at least one post suggesting that it suffers the same fate. In your case, clearly more research is needed.
  • The TRIM issue arises only if an affected drive is the boot device, and then, only if APFS formatted. HFS+ drives are apparently fine.
  • You will notice that the list of drives I referenced are under several headings. For example, the Samsung 970 EVO/PRO is under Working with TRIM broken: As I understand it, with TRIM enabled you can expect the slow boot condition to arise (even if not immediately apparent). Again, only if APFS, and if it's the boot drive. The 970 EVO/PRO can be used as data storage, while some others cannot. It's also fine to use that drive for Windows or Linux - at least, I've read nothing to the contrary.
  • The Buyer's Guide has been updated to include only drives known to be unaffected by the TRIM issue.
I hope this information was helpful.
 
Last edited by a moderator:
This is my result of the test suggested by Dortania

GA-Z370N WiFi - i8700k
Big Sur 11.6.1
Samsung SSD 970 EVO 250G M.2 NVME

  1. 14.43 15.10 15.20
  2. 24.53 25.12 25.10
  3. 29.35 30.22. 28.80
I am not going to change this drive or not upgrading to Monterey as of now. I am using this drive since july 2018, health status is showing 99%

What trimdelay I should set for least damage?
 
This is my result of the test suggested by Dortania

GA-Z370N WiFi - i8700k
Big Sur 11.6.1
Samsung SSD 970 EVO 250G M.2 NVME

  1. 14.43 15.10 15.20
  2. 24.53 25.12 25.10
  3. 29.35 30.22. 28.80
I am not going to change this drive or not upgrading to Monterey as of now. I am using this drive since july 2018, health status is showing 99%

What trimdelay I should set for least damage?
My opinion only: If you have used this drive for three years with Catalina/Big Sur, and you haven't experienced the slow boot generally described, I see no reason to change trim delay from the default.

The slow boot is a symptom of the TRIM issue, and only seems evident when Monterey is the boot device, on an affected NVMe drive. That doesn't mean the issue does not exist in other scenarios, only that it's more noticeable with Monterey, and extremely long boot times are possible.

If you eventually decide that you do want Monterey, you could always buy another unaffected drive at that time, and use the existing one for storage. Good luck.
 
Last edited by a moderator:
Back
Top