Is MacOs deadly for some SSDs?

[MarFre22]

Hi, Thank you everyone who contribute for this project.

My SSD M.2 just died, I think.... hope no... when I was using MacOS Mojave 10.14.5, installed in it. Unexpectedly, it became very very slow and I tuned off the PC holding On/Off button. After that it does not work. So I'd like to ask if there are some SSDs that MacOS is bad to install (excepting the Samsung Evo 970 that was said it make kernel panics). If is better for lifespan using MacOS in a NVMe or SATA SSD drive or WD drives are worse to install to do Hackintosh.

My SSD is WD Blue 500GB M.2 SATA.

Also you can say which SSD M.2 you think better for hackintosh in Mi Notebbok Pro.

Thank you very much for the help!

[stevezhengshiqi]

Please refer to Buyer’s Guide in tonymacx86. https://www.tonymacx86.com/buyersguide/building-a-customac-hackintosh-the-ultimate-buyers-guide/#Solid_State_Drives

This repository would become so big and messy if it includes everything in detail. General set up questions can always be found in tonymacx86.com, and I learned a lot from that website too.

[MarFre22]

I have been searching for anything related to it in Tonymacx86. I found that Samsung 970 Evo doesn't has any issues, I think. But are there differences between 970 plus and 970 also related to MacOS compatibility? In this project was said that PM981 is not recommended to hackintosh, but it is like a 970 Evo, I think, so are there huge differences in compatibility between them?

Also are Trim and APFS or HFS+ affecting the compatibility and lifespan of SSDs? I think APFS is more life friendly for SSDs, but there are people who use HFS+ to have a faster boot, so what do you think about it?

[Menchen]

Personally I use 970 evo with apfs and trim without issue. You shouldn’t care much about sad lifespan as even without trim, it will last much longer than your laptop

[MarFre22]

All right. I order a new 970 Evo, hope for super quick MacOs ⚡. Thank you both for the support.

[ZambraDesigner]

Hi @Menchen , I also use Samsung SSD 970 EVO but the battery doesn't last very long. With normal use I can do just over 2 hours .. how long does it last for you?

Personally I use 970 evo with apfs and trim without issue. You shouldn’t care much about sad lifespan as even without trim, it will last much longer than your laptop

[MarFre22]

@Menchen I already have my 970 evo (500GB), but I feel it has an poor performance compared with Windows. For example, it take 10/15min to transfer 5GB of data.

Sorry for the question. Is your 970 evo performing well in daily use?

[Menchen]

Mine is working fine, I have seem 300mb/s copying files. I can do a benchmark if you want.

[MarFre22]

@Menchen , I feel the performance is better with the EFI updates but I only have, max, 2300MB/s Write and 2700MB/s Read. Compared with Windows I have 2500MB/s Write and 3400/3500MB/s Read. Is it related to constant TRIM failures due to a not very compatible Samsung Controller (said on other sites)? or can it be solved with some EFI update (NVMeFix kext)?

@ZambraDesigner , In fact 970 Evo isn't very battery efficient compared with others, but it has, supposedly, better performance. SSD's: https://github.com/daliansky/XiaoMi-Pro-Hackintosh/issues/381#issuecomment-616533216 Better battery consumption: https://github.com/daliansky/XiaoMi-Pro-Hackintosh/issues/389

[MarFre22]

Some time ago, I bought the Sabrent Rocket Q 1TB. Despite not being technologically advanced as 970 Evo 500GB, like said here, it has a better performance on MacOS (also with 4k blocks activated). For example, it only takes 1/3 of the time to start the MacOS and it runs cooler.

With the latest EFI (1.4.4), I'd like to ask if it's necessary to use NVMEFix.kext with Sabrent Rocket Q and if it already supports APST. Some info I searched: here, here

[MarFre22]

After some time using Sabrent RocketQ, it has 8TB writed data! I thought it was normal because I have been recording my screen some hours a day. Today my hackintosh was pretty hot and at the end of the evening it wrote 724GB on ssd! I only had Firefox on background and pdf viewer, with Wi-Fi turned off, antivirus off. On activity panel I couldn't see which app was writing, only I saw the writing data always increasing (like +-400mb/s).

Do you have any idea about that?

Xiaomi Pro 2017 i5-8250U MacOS Catalina 10.15.6 EFI 1.4.5 Clover

Edit: after some optimization with CleanMyMac X and Onyx, I think it's stable for now. But I am always getting errors on Console app:

[lvs1974]

@MarFre22: thank you for your observations and suggestions. I have a Dell Inspiron 7590 laptop and use Big Sur 11.1, and my only storage is Samsung EVO 970 Plus 1Tb. MacOS boot speed is slowing down (and it looks like it depends on how many data has been written into APFS container). If I reinstall macOS from scratch (with removing and creating APFS container) - boot speed becomes fine again!

I discovered that it is related to the trim procedure in APFS driver (and driver definitely collaborates with NVME firmware):

2020-12-27 18:11:03.134025+0100  localhost kernel[0]: (apfs) <apfs`log_debug> spaceman_metazone_init:189: disk2 metazone for device 0 of size 959072 blocks (encrypted: 0-479536 unencrypted: 479536-959072)
2020-12-27 18:11:03.134032+0100  localhost kernel[0]: (apfs) <apfs`log_debug> spaceman_datazone_init:442: disk2 allocation zone on dev 0 for allocations of 1 blocks starting at paddr 1081344
2020-12-27 18:11:03.134039+0100  localhost kernel[0]: (apfs) <apfs`log_debug> spaceman_datazone_init:442: disk2 allocation zone on dev 0 for allocations of 2 blocks starting at paddr 1048576
2020-12-27 18:11:03.134045+0100  localhost kernel[0]: (apfs) <apfs`log_debug> spaceman_datazone_init:442: disk2 allocation zone on dev 0 for allocations of 3 blocks starting at paddr 1015808
2020-12-27 18:11:03.134051+0100  localhost kernel[0]: (apfs) <apfs`log_debug> spaceman_datazone_init:442: disk2 allocation zone on dev 0 for allocations of 4 blocks starting at paddr 983040
2020-12-27 18:11:14.999457+0100  localhost kernel[0]: (apfs) <apfs`log_debug> spaceman_trim_free_blocks:3367: disk2 scan took 11.864979 s, trims took 10.120342 s
2020-12-27 18:11:14.999473+0100  localhost kernel[0]: (apfs) <apfs`log_debug> spaceman_trim_free_blocks:3375: disk2 11210158 blocks free in 86549 extents
2020-12-27 18:11:14.999496+0100  localhost kernel[0]: (apfs) <apfs`log_debug> spaceman_trim_free_blocks:3383: disk2 11033936 blocks trimmed in 20225 extents (500 us/trim, 1998 trims/s)
2020-12-27 18:11:14.999513+0100  localhost kernel[0]: (apfs) <apfs`log_debug> spaceman_trim_free_blocks:3386: disk2 trim distribution 1:0 2+:0 4+:3019 16+:8426 64+:4214 256+:4566
2020-12-27 18:11:14.999526+0100  localhost kernel[0]: (apfs) <apfs`log_debug> spaceman_trim_free_blocks:3390: disk2 176222 blocks not trimmed in 66324 extents
2020-12-27 18:11:14.999544+0100  localhost kernel[0]: (apfs) <apfs`log_debug> spaceman_trim_free_blocks:3393: disk2 skipped trim distribution 1:30989 2+:19126 4+:16209 16+:0 64+:0 256+:0

Now I have 2 APFS containers: one for Mojave 10.14.6 and another for Big Sure 11.1. And time required to boot from OpenCore to login screen is doubled! I also noticed that a write/read speed in macOS is also degraded! Write speed is 2700 MB/sec and read speed is 2069 MB/sec.

It looks like I will have to change my Samsung EVO 970 Plus to Sabrent Rocket quite soon (but in DriveDX everything is fine, only 23TB has been written and SMART is perfectly fine). May I ask you to find all occurrences for "spaceman" in you macOS boot log and post them here, please?

[MarFre22]

@lvs1974 Hi, Yes, in fact TRIM is buggy in Samsung Evo 970 and the Plus version.

Where I can find the occurrences for "spaceman"? What am I supposed to do?

[lvs1974]

@MarFre22: you can type the following command in terminal and put output: log show --last 3d --style syslog | grep "spaceman"

Or redirect the output into the file and put the file: log show --last 3d --style syslog | grep "spaceman" > spaceman.txt

[lvs1974]

I uploaded spaceman statistic for a real iMac 27": spaceman.txt It uses external TB3 nvme m.2 - PNY CS3030 (in log from 2020-12-26 17:51:08 to 17:51:18) and internal native Apple SSD (actually Samsung) (in log from 2020-12-26 17:51:30 to 2020-12-26 17:51:32).

It looks like many non-apple nvme devices have issues with APFS trimming (it is slow).

[MarFre22]

@lvs1974 After several attempts, I can not find any "spaceman" related entries. Is it normal? I'm using APFS with Sabrent Rocket Q (with 4k blocks activated).

[lvs1974]

@MarFre22, it is not normal, if you have APFS volumes these "spaceman" entries must be in log after reboot. Probably you rebooted more than 3 days ago, you can remove "--last 3d" and get all entries. Or just reboot and run this command again, please.

[MarFre22]

@lvs1974 Unfortunately, even restarting I don't have any "spaceman" entries. It's because I have windows, macOS, and other ntfs partition on the same drive?

[lvs1974]

@MarFre22, I also have windows and hfs partition on the same drive. You can try to add msgbuf=1048576 into boot-args and type the following command in the terminal (right after boot and login): sudo dmesg | grep spaceman > dmesg.txt

The only case when this string cannot be found in log - booting from HFS+.

[MarFre22]

@lvs1974 Nice, it worked! Thanks!! What do you think about it? dmesg.txt

I'm not using NVMeFix.

EDIT: Yes, its confirmed that 970Evo and Plus version are much slower in Triming. Unfortunately, non Apple SSDs are so slow.

EDIT 2: The PNY CS3030 has good times for non Apple SSDs because it's using Phison Controller: "The XLR8 CS3030 is a Phison PS5012-E12 drive with DRAM and Toshiba 64L BiCS FLASH. In year's past, we could point to a Phison-based drive and say a Phison is a Phison, is a Phison, but that is no longer the case.

Read more: https://www.tweaktown.com/reviews/9011/pny-xlr8-cs3030-low-cost-nvme-ssd-review/index.html"

EDIT 3: Thank you again! Because it's a good compare method to review SSDs for hackintosh world.

EDIT 4: I heard that Samsung 960 series are a nice choice to hackintosh because it has the same controller as Apple ones.

[lvs1974]

@MarFre22, It looks good - only 7.3 seconds for scanning. And if we have a look at speeds: 14590975 blocks trimmed in 131072 extents (25 us/trim, 38573 trims/s) 38573 trims/s - it looks much much faster than mine 1998 trims/s with Samsung EVO 970 plus. And as far as I know - method nx_mount_trim_thread in apfs.kext checks how much time the scanning takes and just skips any extents if time spent for trimming more than 0x98967F (microseconds) - it is 9.9 seconds. You have only 2165 blocks not trimmed in 2165 extents not trimmed blocks, and in my case this value is increasing.

I am testing now my own patch for apfs.kext disabling trimming (it just sets the maximum time to 999 microseconds, so nx_mount_trim_thread does not take much time (only 1-2 seconds maximum). I also turned on over-provisioning for free space (22% - about 200Gb). I think it should work without any issues, even if trim is not working.

[MarFre22]

@lvs1974 it's a pretty good idea, but I'm afraid that Trim is essential for ssd health, isn't it? In that case, your "solution" is to over-provisioning?

Despite that, it's a good work to make the 970 series faster in macOS.

[lvs1974]

@MarFre22, TRIM is not always necessary, in RAID arrays on servers it is not used. I read one topic (unfortunately only in Russian, you can try to translate by google): https://interface31.ru/tech_it/2015/04/mozhno-li-effektivno-ispolzovat-ssd-bez-podderzhki-trim.html It is explained there, that TRIM can be turned off if over-provisioning is big enough.

[MarFre22]

@lvs1974 Oh all right, I didn't know that, thanks! Sorry, but how much do you consider big enough?

[lvs1974]

@MarFre22, I saw 20-25% from total capacity.

[MarFre22]

@lvs1974 Ok I understand. Can you keep me updated on your work? Because it will be nice to write it on the wiki.

[lvs1974]

@MarFre22, Yes, I can. Currently it is not a kext, it is binary patch, but it works for 10.14, 10.15 and 11.1.

[MarFre22]

@lvs1974 Nice! Thanks! Ok, understood :) Keep the good work 💪

[lvs1974]

I am still testing my setup with a binary patch (turning off trim in apfs.kext) and over-provisioning. So far it looks good, boot speed is fine, there is no any side effects. But if somebody wants to try my patch: I am not responsible for any damages of hardware or file system(s). If you take this risk - please backup everything!!!

Idea behind this patch: When any boot apfs volume is mounted, a special thread is run by apfs.kext - nx_mount_trim_thread. Volume cannot be accessed until this thread is finished. In macOS Mojave 10.4 some timing checks were introduced in order to skip trimming of apfs extents (probably there were some complaints about boot speed).

nx_mount_trim_thread:

At start:
microuptime(&tv);
v26 = 1000000 * tv.tv_sec + tv.tv_usec;

Timeout:
v8 = (unsigned __int64)(tv.tv_usec + 1000000 * tv.tv_sec - v26) > 0x98967F;

If v8 has non-zero value, all further extents will be not trimmed.
asm: cmp     rax, 98967Fh

0x98967F it is 9999999 microseconds (9.999999 seconds).

Patch to reduce timeout (what I am currently testing): Use 999 (0x3E7) instead of 9999999 (1 millisecond): Find: 48 3D 7F 96 98 00 Replace: 48 3D E7 03 00 00 Kext identifier: com.apple.filesystems.apfs

Patch to disable timeout (all extents will be trimmed): Find: 48 3D 7F 96 98 00
Replace: 48 3D FF FF FF FF Kext identifier: com.apple.filesystems.apfs

[lvs1974]

This patch now is available as a quirk SetApfsTrimTimeout in OpenCore 0.6.6: https://github.com/acidanthera/OpenCorePkg/commit/f45df2f1241eaeab933ba672b20066f5b7d0a68c

You can download pre-built OC binaries here: https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true&version=0.6.6&sha=f45df2f1241eaeab933ba672b20066f5b7d0a68c