Most SSD manufacturers that make filesystem-aware SSD's that don't need OS TRIM support only bother to work with the NTFS filesystem anyways, so you would still need to enable TRIM with OS X regardless. The problem is, filesystems change and there are a lot of them out there. And even if it did, it's not a very good solution either. I have never heard of Sandforce SSD controllers being file-system aware, and thus able to handle TRIM without the need of OS TRIM support. This reduces the average number of writes to cells in the SSD and can greatly prolong the lifespan of the SSD as well. With TRIM, the OS tells the SSD which data is no longer needed, and the SSD will know that it doesn't need to save this data to new blocks during garbage collection. This is a huge waste of time and greatly increases the number of writes that the SSD performs over its lifetime. When the SSD goes to consolidate it's "good" data to free up space, if the OS has not told the SSD which data has been marked as no longer needed by the OS, the SSD will write this "unneeded" data to new blocks during garbage collection. So if you have some good data in that block, it needs to be copied to a new location before the entire block can be erased.Īnd that is where the problem is, and why TRIM is so vital with SSD's. The reason for this is because an SSD cannot choose to only delete part of a block, it is an all-or-nothing process. When some data in a block is marked as being no longer needed by the OS, the best thing the SSD can do is to copy the "good" data out of the block and in to a new sector. This is why TRIM is necessary except in very specific implementations. I see a second occurrence of a very similar pattern a bit further in the file: "APPLE SSD TS".SSD's have very unique limitations when it comes to writing data. 0201720 0a79 0000 0000 0000 0000 0000 5400 6d69ĮDIT: I just realised this patch replaces the string "APPLE SSD" with as many null bytes. ![]() > md5sum /System/Library/Extensions/IOAHCIFamily.kext/Contents/PlugIns/IOAHCIBlockStorage.kext/Contents/MacOS/*ħ9f51aaf114f3dd8be5e409f6e3c13df /System/Library/Extensions/IOAHCIFamily.kext/Contents/PlugIns/IOAHCIBlockStorage.kext/Contents/MacOS/IOAHCIBlockStorageĮf72c0c2bfb1074bf400d3405efdae10 /System/Library/Extensions/IOAHCIFamily.kext/Contents/PlugIns/IOAHCIBlockStorage.kext/Contents/MacOS/IOAHCIBlockStorage-backupĦ1 0 0xffffff7f813bb000 0x18000 0x18000 (2.6.0) Ĭontents comparison, does this look correct? > od -x IOAHCIBlockStorage-backup > /tmp/kk1 I think I've applied the correct patch from the list above but I cannot seem to find the indicator for my external Kingston SUV500MS120G (SSDNow family). Run these commands in succession to clear the system caches to enable OS X to pick up the modified driver: sudo kextcache -system-prelinked-kernelĮxactly where am I supposed to see the trim enabled indicator on OS X 10.9.5? Sudo perl -pi -e 's|(^\x00\x4D)|$1\x00\x00\x00\x00\x00\x00\x00\x00\x00$2|sg' /System/Library/Extensions/IOAHCIFamily.kext/Contents/PlugIns/IOAHCIBlockStorage.kext/Contents/MacOS/IOAHCIBlockStorage Modify the driver (choose only one of the following lines, based on the version): # 10.9.4
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |