I have found this to be very true!... So much that I reverted TRIM. For work I do a bunch of deleting and compiling and it was affecting build times.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
TRIM Support Enabler
- Thread starter Cindori
- Start date
- Sort by reaction score
I have found this to be very true!... So much that I reverted TRIM. For work I do a bunch of deleting and compiling and it was affecting build times.
Erase free space is not needed if you have mbp 2011 and do fsck.
Fsck makes trimming the free space like it is intended to do.
Erase free space writes a large temporary file with zeros, then removes it. It should do the trim as well for the removed file, but it wears the disc for one write cycle.
At least I noticed after fsck with xbench, that speeds are increased, e.g linear 4kb read speed increased 25 -> 28MB/s and random 19 -> 20MB/s.
I didn't notice speed increase with erase free space.
Code:
Results 335.62
System Info
Xbench Version 1.3
System Version 10.6.7 (10J3250)
Physical RAM 4096 MB
Model MacBookPro8,1
Drive Type Corsair CSSD-F120GB2
Disk Test 335.62
Sequential 201.25
Uncached Write 299.75 184.04 MB/sec [4K blocks]
Uncached Write 270.05 152.79 MB/sec [256K blocks]
Uncached Read 97.88 28.64 MB/sec [4K blocks]
Uncached Read 381.76 191.87 MB/sec [256K blocks]
Random 1009.81
Uncached Write 1453.42 153.86 MB/sec [4K blocks]
Uncached Write 519.18 166.21 MB/sec [256K blocks]
Uncached Read 2838.96 20.12 MB/sec [4K blocks]
Uncached Read 1005.28 186.54 MB/sec [256K blocks]
Last edited:
Hello,
If XBench gave consistent results test after test, it would be significant. As things are, until we get a truly consistent benchmark utility, small differences aren't usually meaningful.
Loa
If XBench gave consistent results test after test, it would be significant. As things are, until we get a truly consistent benchmark utility, small differences aren't usually meaningful.
Loa
People with slow delete, please check your sector alignment is correctly 4096 bytes. See thread
https://forums.macrumors.com/threads/952904/
https://forums.macrumors.com/threads/952904/
No, read the dialog when you hit "erase free space". It clearly says it will overwrite the data with 0's so you can't recover it. In other words, it will fill the cells with new data so you can't get to the old. But that would mean you can't use it any more so it will mark the cells with a 0 in them as "reusable" (it deletes the data it has written). This causes TRIM to be triggered and clear out the cells.
Fsck is a utility for when things go bad, it will check and repair the filesystem (if possible). Apparently they've now added the option to trim unused blocks for trim-enabled ssd's. With most unix/linux systems fsck will run upon (re)boot but mostly only check filesystems that are not marked as clean. So for some this might mean that by simply rebooting after using TRIM enabler the drive will be trimmed (you can check fsck_hfs.log in Console if it did).
The two utilities are just different things.
There will definitely be problem with the file system if you just block-level clone your HDD to SSD with Disk Utility or Carbon Copy Cloner. You should format and partition the SSD with Disk Utility and disable Erase Destination when you restore from the HDD to the SSD. This way you will do file copy to the SSD instead of block-level copy and avoid potential file system problems. One example is the adaptive hot-file clustering that's not used for SSD. If you perform a block-level copy you will have hot-files within the metadata zone and the catalog and allocation files will not be correct.
Last edited:
There can also be some sort of incompatibility between the file system and the SSD controller's wear-leveling when using the trim command.
Awesome patch Cindori -- Thank you!!! I just upgraded my 500GB 5400 RPM drive in my 2010 MacBook Pro with a new Intel 320 300GB SSD. Reinstalled OS X, updated, ran the patch, and everything appears to be working great!
Cindori, given what we've found out about fsck_hfs since then, don't you think your patch should install both the hacked TRIM kext and the 491.6 fsck_hfs binary from the MacBook Pro 2011 10.6.7 release?
There are references in fsck_hfs to other updated dynamic loaded shared libraries and some localization files in the MPB 2011 10.6.7 update so it would require some extensive testing and there might also be a new updated version of diskutil in the MBP 2011 10.6.7 release.
I applied this patch, but have since backed it out again. After running it I started noticing stability problems, especially with processor utilization increasing to the point where my MBP became unusable and required a reboot to return to normal. Since undoing the patch, everything seems OK again.
System runs better
This patch has improved the performance of my system. Once or twice a week my Logitech keyboard and mouse would not be recognized by my late 2010 Mac Pro running 10.6.7. I have have to hold the power button to restart.
After formatting and clean reinstalls of Snow Leopard, and still having this Logitech problem, I no longer have it after this patch. Been running since the first day it came out. THANKS!
This patch has improved the performance of my system. Once or twice a week my Logitech keyboard and mouse would not be recognized by my late 2010 Mac Pro running 10.6.7. I have have to hold the power button to restart.
After formatting and clean reinstalls of Snow Leopard, and still having this Logitech problem, I no longer have it after this patch. Been running since the first day it came out. THANKS!
RS2...spin this off in a separate thread if necessary so we don't hijack this one, but can you explain this in more detail? I have restored images to my SSD using CCC with "Erase Destination", and don't have any problems...After restoring the image and repairing permissions using Disk Utility, I don't see any permission that need significant repair (there are a few, but not necessarily significant)...
Wirelessly posted (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/533.20.25 (KHTML, like Gecko) Version/5.0.4 Safari/533.20.27)
Installed on my 2011 15" MBP with Intel 510 SSD with no problem. However, whenever the computer went to sleep it would beachball and freeze up. As such, I had to restore to the original drivers.
Installed on my 2011 15" MBP with Intel 510 SSD with no problem. However, whenever the computer went to sleep it would beachball and freeze up. As such, I had to restore to the original drivers.
Interesting, after working with TRIM for a few days I suddenly noticed Firefox 4 would "hang" (beachball) while scrolling and browsing through pages. No visible CPU bottlenecks, and only about half of my 8GB of RAM was being used. I restored from the kext backup to disable TRIM, will see if that was the problem (as based on other reports it probably was). The TRIM command may currently be too "aggressive," sending after every small file is moved or deleted, which happens a lot with a browser cache...so that may be the cause of slowdowns, and may be why TRIM support isn't yet official and supported by Apple for all drives.
I just thought of this, as I haven't been having the Chrome or Firefox stalling problems others are reporting. My SSD is the 80GB Intel G2.
I'm not having any problems on the Snow Leopard side and have my user folder still on the SSD so not sure why others are having problems.
I'm not having any issues on Windows 7 via Bootcamp, but I had my TEMP folder redirected to a regular HD (did this for longevity reasons pre Cindori's Trim program).
Just thinking outloud.
I'm not having any problems on the Snow Leopard side and have my user folder still on the SSD so not sure why others are having problems.
I'm not having any issues on Windows 7 via Bootcamp, but I had my TEMP folder redirected to a regular HD (did this for longevity reasons pre Cindori's Trim program).
Just thinking outloud.
I have my user folder on my SSD except for things like my music and photo libraries (symlinked to my 640GB hard drive). If anything, maybe moving your user/home folder completely to the HDD would fix these issues, as the browser cache wouldn't be triggering TRIM commands to the SSD. Of course doing this would keep you from enjoying SSD speeds, so for now if this is the source of the problem, I'll stick with TRIM disabled and wait for Apple to improve the implementation. (Maybe so it lumps many small TRIM commands into one larger one, executed only every few minutes or something.)
Also, running without TRIM for a while and then TRIMing once will restore your drive just the way it would be if you were TRIMing all along. So even just enabling and erasing free space once a month should do the trick quite well. And the more free space (unused capacity) on your SSD, the less it's a problem anyways.