- Joined
- Jul 24, 2015
- Messages
- 2,191
- Motherboard
- MSI H81i
- CPU
- i5-4570
- Graphics
- RX 580
There is a model check in linux that blacklists certain drives from queued TRIM commandsAPFS disaster finally struck. I did some minor configuration changes to my APFS HS, with trim enabled in my config.plist file, after which I decided to reboot. The result of that reboot was pages and pages of inode errors. When the scrolling inode error pages finally stopped I tried to reboot again but the scenario was identical to my first boot with pages and pages of inode errors. I then fired up my spare High Sierra on HFS+ J, reformatted the SSD "Samsung 850 EVO 500GB with APFS. Using CCC I then recloned HS back to the SSD. Recloning just over 50 GB took 12 mins. 27 secs. I then implemented the original intended changes, rebooted and everything is working just fine again. HS on APFS was active and working flawless from 27 Sept. till today, merely 7 days. Food for thought indeed, and perhaps an eye opener for those that are prepared to put all their eggs in one basket and rely entirely on High Sierra on an APFS formatted drive. After this experience I have to conclude that APFS is certainly not ready yet to be deployed in a mission critical environment.
This problem manifested itself on my Skylake build.
Cheers
Code:
/* devices that don't properly handle queued TRIM commands */
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Micron_M5[15]0_*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M550*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*MX100*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Samsung SSD 8*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "FCCT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, }