...its going to be interesting comparing the intel g2 80Gb drive in my whitebook to the 64 Gb WD going into my eeePC (when it hopefully gets here next week)...
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.
In the absence of OSX TRIM support, how do you restore SSD performance on a Mac?
- Thread starter Libertine Lush
- Start date
- Sort by reaction score
...actually I wish I hadn't ordered the intel drive before I got the price I got on the WD drives as this unit has its own internal garbage collection, that would have been a better comparison to use both of the WD drives in my winXP netbook and my whitebook side by side...
The intel gets great reviews but the specs on the WD drive seem to be so much higher for WD's first try at a SSD...
The intel gets great reviews but the specs on the WD drive seem to be so much higher for WD's first try at a SSD...
Here's the thing.
TRIM is not GC, and it's not (as far as I can tell) been wedged into a low-level format operation,although that's a possibility I guess.
Secure erase, dumping zeroes into blocks, any every other permutattion of that will not fix the problem. TRIM requires knowledge of the filesystem in use (except in the case that you are wiping the entire device - which is where us MAC users are probably stuck unless Apple gets TRIM into the filesystem drivers).
TRIM is something that did not exist on magnetic media - a completely out of context operation. It's a new functional requirement all by itself. SSDs need to have their cells "reset" - which is not the same as writing zeroes to the entire cell - zeros are still data.
It's not the same as secure erase, which just runs multi-pass writes with random (or specifically calculated) over this same physical blocks in order to prevent forensic recovery of data. This is likely unnecessary, or at least fundamentally differnet, on SSD devices, and will likely end up simply reducing the lifespan of your SSD unnecessarily.
GC as implement seems to be more about wear-levelling and shuffling data around in the background so that unallocated cells are used in place of allocated ones - and it's always possible (I forget if htis has already been done) that some filesystem logic will be placed in the drive firmwares themselves, allowing them to handle TRIM as part of GC... but that doesn't solve the current problem.
What we need, therefore, until Apple implements TRIM, or someone else comes up with a stable HFS+ TRIM driver, at least for the Intel X25M SSDs, is a bootable CD that can TRIM/wipe/reset (whatever) the entire device so we can clone the filesystem to a backup device, spring-clean the SSD, and then clone it back.
As to performance not degrading - if most of your operations are read operations you won't see it - read speeds are unaffected. I've been running xbench periodically since installing my SSD and while read speeds remain the same, write speeds have dropped dramatically once I blew through all the SSD allocation units. Does this negatively impact my experience? not really - for daily use it's still stupid fast, and the writes are still fast.... but they're a good deal slower than they were when it was fresh.
Again - this isn't something that can be solved simply by a firmware upgrade or some new drive logic (unless the drives plan to understand every filesystem out ther) - it's something that must be handled at the filesystem/block device barrier. We will certainly see better and better performance, and better and better firmware and hardware, but fundamentally, the concept of TRIM is new, and needs to be addressed in the OS, not in the drive - no getting around that.
So - it seems reasonable that we should be able to come up with at least a grey-market bootable image of some kind that can at least wipe/reset/TRIM some specific SSDs to prepare them for re-imaging - and if anyone can wrap their head around HFS+ and it's block allocation mechanisms, possibly a tool that can take care of trimming the unused blocks.
TRIM is not GC, and it's not (as far as I can tell) been wedged into a low-level format operation,although that's a possibility I guess.
Secure erase, dumping zeroes into blocks, any every other permutattion of that will not fix the problem. TRIM requires knowledge of the filesystem in use (except in the case that you are wiping the entire device - which is where us MAC users are probably stuck unless Apple gets TRIM into the filesystem drivers).
TRIM is something that did not exist on magnetic media - a completely out of context operation. It's a new functional requirement all by itself. SSDs need to have their cells "reset" - which is not the same as writing zeroes to the entire cell - zeros are still data.
It's not the same as secure erase, which just runs multi-pass writes with random (or specifically calculated) over this same physical blocks in order to prevent forensic recovery of data. This is likely unnecessary, or at least fundamentally differnet, on SSD devices, and will likely end up simply reducing the lifespan of your SSD unnecessarily.
GC as implement seems to be more about wear-levelling and shuffling data around in the background so that unallocated cells are used in place of allocated ones - and it's always possible (I forget if htis has already been done) that some filesystem logic will be placed in the drive firmwares themselves, allowing them to handle TRIM as part of GC... but that doesn't solve the current problem.
What we need, therefore, until Apple implements TRIM, or someone else comes up with a stable HFS+ TRIM driver, at least for the Intel X25M SSDs, is a bootable CD that can TRIM/wipe/reset (whatever) the entire device so we can clone the filesystem to a backup device, spring-clean the SSD, and then clone it back.
As to performance not degrading - if most of your operations are read operations you won't see it - read speeds are unaffected. I've been running xbench periodically since installing my SSD and while read speeds remain the same, write speeds have dropped dramatically once I blew through all the SSD allocation units. Does this negatively impact my experience? not really - for daily use it's still stupid fast, and the writes are still fast.... but they're a good deal slower than they were when it was fresh.
Again - this isn't something that can be solved simply by a firmware upgrade or some new drive logic (unless the drives plan to understand every filesystem out ther) - it's something that must be handled at the filesystem/block device barrier. We will certainly see better and better performance, and better and better firmware and hardware, but fundamentally, the concept of TRIM is new, and needs to be addressed in the OS, not in the drive - no getting around that.
So - it seems reasonable that we should be able to come up with at least a grey-market bootable image of some kind that can at least wipe/reset/TRIM some specific SSDs to prepare them for re-imaging - and if anyone can wrap their head around HFS+ and it's block allocation mechanisms, possibly a tool that can take care of trimming the unused blocks.
This doesn't compute, because the partition map and filesystem super blocks are meta-information interpreted by the filesystem drivers - they are differenet for every type of filesystem. The SSD itself doesn't know a superblock from a regular block - it's just a block. This is why TRIM is so important.
GC-like functions that are filesystem-aware may work as a partial solution - but it's going to be fairly limited in application to only those filesystems that it knows about.
TRIM really does need to be implemented by the filesystem drivers - there's no way around it - the bottom line is that hard drives ,as we've known them up until now (not counting the new "ATA secure erase" functions) - have been completely agnostic block storage devices that didn't need to know anything about what was stored on them. SSDs are changing that.
...well, either I was expecting too much from the WD SSD or the CPU in my netbook is just really weak (its an Atom N270 1.6 Ghz with the 533 Mhz FSB and 2 Gb Ram).
I'm thinking of doing a clean install of winXP vs. the clone of the original HDD I originally did... its a "little" snappier but not what I was expecting vs. the WD Scorpio blue 250 Gb HDD it replaced...
I haven't installed the Intel drive yet for comparison....
...well, either I was expecting too much from the WD SSD or the CPU in my netbook is just really weak (its an Atom N270 1.6 Ghz with the 533 Mhz FSB and 2 Gb Ram).
I'm thinking of doing a clean install of winXP vs. the clone of the original HDD I originally did... its a "little" snappier but not what I was expecting vs. the WD Scorpio blue 250 Gb HDD it replaced...
I haven't installed the Intel drive yet for comparison....
...UPDATE, I just finished doing a clean install from the Ghost CD for my eeePC and it is very fast now compared to when I used XXClone to clone the old WD Scorpio blue HDD over to this WD Scorpio Blue SSD...
The clone software must have not done something very well as this last week I had a C++ update and 2 .net framework updates that wouldn't install at all using any of the cleaners/installers that were supposed to "never" fail...
I'm happy with this SSD now and the eeePC feels much faster!
Moral of the story, clean installs FTW
...I wanted the wear leveling and GC of the WD drive and its 64Gb vs the 40 Gb of the intel "v" unit as well...
I'm not a linux user at all, never used it until this week when I wanted to rejuvenate my MBP apple SSD.
I followed the instructions provided at
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
Thanks MBHockey. Quality!
I did not have to hot-swap, I simply used the trick indicated at Step 1a:
Put linux in sleep mode, wake it up immediately after. it takes 10 seconds and the drive is not frozen anymore. the rest was as easy as it could get, and again, this was the first time I used linux.
the erase took 31 seconds
the terminal looks scary to use but just follow everything to the letter and you'll be fine. I did have to make one single change: I had to add sudo in front of each command, otherwise i got a "permission denied" error message.
I did all of this from Ubuntu a 10.04 LTS live CD
I restored the SSD from a superduper backup. Everything went fine.
the average speed was 66.45 MB/s (via a G-RAID Mini on firewire 800). It was done in 27 minutes. I think I'm gonna do this refresh every 2 months.
Let's hope that in the near future, apple will bring some TRIM support in mac os.
Thanks a zillion for this thread.
Nice -- i didn't know about the sleep trick...great tip! Now I won't have to unscrew the casing just to hot plug it. Glad to see everything else worked for you.
So one newb question: Will a future update of OSX potentially fix this TRIM support issue or will only future new Macs have this? Essentially my question is: Can TRIM support be added ex-post or only with new systems?
So one newb question: Will a future update of OSX potentially fix this TRIM support issue or will only future new Macs have this? Essentially my question is: Can TRIM support be added ex-post or only with new systems?
yes.
edit:sorry
yes this can be added on future OSes with older hardware.
It's the SSD ya gotta worry about.
I'm not a linux user either, and though I'm generally pretty decent with computers I can't seem to get past the first step in those instructions:
What did you put for the X? If I try /dev/sda it tells me I don't have permission and if I try /media/SSD which I believe is the path to the drive I get an "inappropriate ioctl" error.
Any ideas?
I havn't done an ATA_SE in a while but if I recall....the "X" should be your device name like disk0 or something. There should be a partition utility that either opens up on bootup of the ubuntu distro mentioned in the wiki, or you should be able to navigate to it. Either way, making sure it's the only drive connected to your system will make it a bit easier.
Thanks. I got it figured out. Turns out /dev/sda was the correct drive, I just needed to put a sudo in front of all the commands. I'm not really sure what I just did or why it was necessary but I'm crossing my fingers that it'll alleviate some of the hangups I've been getting.
Yes, like I wrote back in September, you have to put sudo in front of the command.
and sda is also my first drive (on the mac book pro)
Put sudo in front of it if it's giving you permission errors - that just tells it to run it as root.
Code:
sudo hdparm -I /dev/sda
It would be nice if OSX had a built in feature that did true secure erases. My Intel SSD is in slight need of a factory refresh.
Per the comments on made on the first post from the Mac Performance Guide, I just kept it simple, and installed a Mercury Extreme SSD from OWC, given theses have not shown performance degradation over time.
Call me lazy, but I have no interest in trying to keep up with the nuances of TRIM support (or lack thereof on the Macs), Garbage Collection, reformatting, etc. I just wanted something that plain works, for a long time. So far, I'm loving my OWC drive.
Call me lazy, but I have no interest in trying to keep up with the nuances of TRIM support (or lack thereof on the Macs), Garbage Collection, reformatting, etc. I just wanted something that plain works, for a long time. So far, I'm loving my OWC drive.
Seems like the OWC is gonna be my next SSD drive. Intel is great but no trim support in OSX is a big no-no.
This is simple.
I have had two Intel G2 drives and the following happens to both (Although it takes longer on the 160Gb because it's only 50% full compared to 80% full of the 80Gb).
Over time the performance (XBench, Finder file transfers, AJATest or whatever) slows down.
The *only* solutions to this is:
1. Secure erase
2. In the case of Intel SSDs, booting into Windows, wiping the SSD and using Intel Toolbox.
This is the cruical bit:
DO NOT USE DISK UTILITY IN OS X TO WRITE ZEROS TO FREE SPACE, IT MAKES THINGS WORSE.
Simples really.
PS: Performance degradation is very, very slow. It takes months for a half empty drive to even start to see big downfalls in performance.
The 80Gb drive took a few weeks mainly because the 10Gb of free space was written over frequently...
I have had two Intel G2 drives and the following happens to both (Although it takes longer on the 160Gb because it's only 50% full compared to 80% full of the 80Gb).
Over time the performance (XBench, Finder file transfers, AJATest or whatever) slows down.
The *only* solutions to this is:
1. Secure erase
2. In the case of Intel SSDs, booting into Windows, wiping the SSD and using Intel Toolbox.
This is the cruical bit:
DO NOT USE DISK UTILITY IN OS X TO WRITE ZEROS TO FREE SPACE, IT MAKES THINGS WORSE.
Simples really.
PS: Performance degradation is very, very slow. It takes months for a half empty drive to even start to see big downfalls in performance.
The 80Gb drive took a few weeks mainly because the 10Gb of free space was written over frequently...
Well I did a secure erase using Ubuntu 10.10 LiveCD on my Mac Mini server. I had an issue booting from the CD so I had to use rEFIt to get it running. After that I put the Mini to sleep to unfreeze the drive and then erased the drive with a few simple command lines in terminal (I also had to put "sudo" in front of command).
My Intel drive is back to factory speeds. This should be a sticky for conducting an ATA secure erase on a mac.
My Intel drive is back to factory speeds. This should be a sticky for conducting an ATA secure erase on a mac.