Contribute
Register

Big delay during boot

Status
Not open for further replies.
Hi @macntosh ,

@pastrychef uses a WD SN750 in his Golden Build, the Gigabyte Gaming Z390M

Thanks @tedyun - @chrispe might be interested in that.

@pastrychef didn't specifically mention that his WD SN750 didn't suffer from the slow boot issue; nor he didn't say it did. As I understand it, the slow boot issue only revealed itself when booting Monterey; is his Golden Build running Monerey yet? The link he gave shows the WD SN750 as working fine with trim, though, so seems promising to me.
 
Thanks @tedyun - @chrispe might be interested in that.

@pastrychef didn't specifically mention that his WD SN750 didn't suffer from the slow boot issue; nor he didn't say it did. As I understand it, the slow boot issue only revealed itself when booting Monterey; is his Golden Build running Monerey yet? The link he gave shows the WD SN750 as working fine with trim, though, so seems promising to me.

Hi @macntosh -- I hope the WD SN750 works! I just got a 2TB and will be installing Monterey on it when I have a chance. It will be a big production though I have to take apart my rig just to get at the M2 slot! I think they should change the Buying Guide to reflect these problems with the Samsung. I bought the Samsung EVO specifically because I thought they were the most compatible with the Hackintosh, and they command premium pricing too!
 
Hi @macntosh -- I hope the WD SN750 works! I just got a 2TB and will be installing Monterey on it when I have a chance. It will be a big production though I have to take apart my rig just to get at the M2 slot! I think they should change the Buying Guide to reflect these problems with the Samsung. I bought the Samsung EVO specifically because I thought they were the most compatible with the Hackintosh, and they command premium pricing too!
I've had no issues with just a standard SSD (Samsung 860 EVO). I guess it's just the luck of the draw. :lol:
 
Last edited by a moderator:
its not stuck its doing trim
check with this
log show --predicate "processID == 0" | grep spaceman
What is the normal time for that? I have the following log:
Code:
2021-11-02 01:32:47.114207+0700 0x281      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:625: disk2 allocation zone on dev 0 for allocations of 1 blocks starting at paddr 57868288
2021-11-02 01:32:47.114210+0700 0x281      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:625: disk2 allocation zone on dev 0 for allocations of 2 blocks starting at paddr 19988480
2021-11-02 01:32:47.114213+0700 0x281      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:625: disk2 allocation zone on dev 0 for allocations of 3 blocks starting at paddr 52756480
2021-11-02 01:32:47.114216+0700 0x281      Default     0x0                  0      0    kernel: (apfs) spaceman_datazone_init:625: disk2 allocation zone on dev 0 for allocations of 4 blocks starting at paddr 51740672
2021-11-02 01:32:47.135523+0700 0x17c      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3171: disk2 scan took 0.021270 s (no trims)
2021-11-02 01:34:40.575317+0700 0x3f9      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3153: disk2 scan took 113.439774 s, trims took 113.308382 s
2021-11-02 01:34:40.575332+0700 0x3f9      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3155: disk2 12583470 blocks free in 299889 extents
2021-11-02 01:34:40.575345+0700 0x3f9      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3163: disk2 12583470 blocks trimmed in 299889 extents (377 us/trim, 2646 trims/s)
2021-11-02 01:34:40.575359+0700 0x421      Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3166: disk2 trim distribution 1:84219 2+:50188 4+:74870 16+:48595 64+:29684 256+:12333
 
Thanks @tedyun - @chrispe might be interested in that.

@pastrychef didn't specifically mention that his WD SN750 didn't suffer from the slow boot issue; nor he didn't say it did. As I understand it, the slow boot issue only revealed itself when booting Monterey; is his Golden Build running Monerey yet? The link he gave shows the WD SN750 as working fine with trim, though, so seems promising to me.

My SN750s boot fast.
 
Swapped-out my Samsung 960 EVO for a WD SN750 SE NVMe (500GB), and boot time is back to normal now, running Monterey 12.0.1. BTW, another M.2 slot in my Hack is still occupied by a Samsung 970 EVO Plus with Windows 11 on it, but its presence alone has no impact on Mac boot time.
 

Attachments

  • Screen Shot 2021-11-02 at 8.48.10 AM.jpg
    Screen Shot 2021-11-02 at 8.48.10 AM.jpg
    386.8 KB · Views: 58
It looks like only the way is clean install with full disk formatting will work (at the current moment): https://forums.macrumors.com/thread...r-slow-boot-on-monterey.2310537/post-30552734

Thanks for posting this. I had the slow boot problem with a SATA Sanidisk SSD and this solution worked. Back to normal.

1) backup the SSD on a regular HDD
2) Erase the SSD with disk part on Windows (clean command, do not create partition primary)
3) Format the SSD on macOS
4) Clone the HDD on the SSD, no data loss
5) Done
 
I've recently installed new copy of Montery to my second Nvme 970 Evo Plus. I formated that full drive as APFS using Disk Util. I got the great results in terms of booting time. The second system starts even faster than BigSur was launched before from the first drive.
I made several tests to measure disk speed. The results are incredible as well.
So, it looks like I need to set up the work environment on my second system and remove the current one from the first Nvme 970 Evo Plus.
My both drives are the same (1TB) and have the latest firmware installed, that I downloaded from Samsung website.
Conclusion:
Samsung Nvme2 970 Evo Plus works fine with Montery, but the system should be installed from scratch (the disk should be formatted before installation)
 

Attachments

  • 1.png
    1.png
    993.2 KB · Views: 74
Status
Not open for further replies.
Back
Top