In the absence of OSX TRIM support, how do you restore SSD performance on a Mac?

[DarthSnuggles]

I've had an X-25 in my Macbook ever since the G2s came out. I do software development, which is 'horrible'. Yea, well I ran XBench. Sure enough, the performance degraded. I don't care. You know why?

Because random writes are *still* literally 10x faster than the stock drive

 

[ayeying]

how low level are we talking?

is there any sort of polarity issues (or something similar, not sure what to call it) like mechanical hard drives? anybody have any idea?

i only ask, because say with mechanical hard drives - if you use DD etc it will change the data to a "0" or "1", but still the polarity of the hard drive at the lowest level still may be very hard to read. is this also the same with SSDs?

SSDs dont have polarities since they don't use a magnetic field to write 0s and 1s.

I'm not entire sure how "low" level its formatting but its the same tools that OEMs use to recondition their SSDs so it should be pretty low level

 

[Thiol]

i wish he explained it a bit more! that doesnt convince me very much. i know he's smart, but yea.. i might just ask nano lol

Writing 0s is the equivalent of completely filling up the drive. A "0" is not empty, it's just different from "1". Now, when an SSD is full, it takes longer to write to it:

http://www.anandtech.com/show/2829/4

 

[MBHockey]

Boot from a Linux disc and issue the secure erase ata command from there using 'hdparm'

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

 

[DoFoT9]

SSDs dont have polarities since they don't use a magnetic field to write 0s and 1s.

i knew it would be something like that, its the same as RAM etc pretty much - but how does that work lol?

I'm not entire sure how "low" level its formatting but its the same tools that OEMs use to recondition their SSDs so it should be pretty low level

i wonder if SpinRite can do it? its the lowest level for mechanical hdds

Writing 0s is the equivalent of completely filling up the drive. A "0" is not empty, it's just different from "1". Now, when an SSD is full, it takes longer to write to it:

http://www.anandtech.com/show/2829/4

now THAT's what im talking about! what a great article

i knew writing 0s or 1s was never going to increase performance because of the changeover factor - but is there a way to NULLify all the blocks so that writing times are pretty much instantaneously without the need to copy to new/erase old/write to new?
edit: ahh the TRIM command, of course. what about for us mac users? a reformat?

 

[Robb.Penoyer]

OK... for us Mac users, there are a couple things to keep in mind:

a) Mac OS is specifically designed to prevent disk fragmentation --- which is effect is the issue at hand for SSD's. They need to first "clear" storage if it was previously occupied and being re-written to.

b) Trim is a device command which would require an OS driver to take advantage of it. Mac OS does not have this, however, the better SSD's have implemented their own form.

c) Some vendors have gone even further, OCZ for example, with their garbage collection, spending time with Apple engineers tuning the performance. (OCZ has a Mac edition drive)

d) Even IF you lost 40% of the performance of your SSD --- and that's a really big if, you would still see a 200 to 300 % increase over a regular mechanical drive.

So, if you find yourself needing to reset your SSD back to fresh fro mthe factory performance.
Step1: use Carbon Copy or Super Duper to create a fill image of it
Step2: Using disk Utility, delete the partition(s) on it
Step3: use Carbon Copy or Super Duper to restore it

The whole process should take about an hour. The reason this works is because removing the partition map, clears the file system "super blocks" which hold the free inode lists --- the codes that says where free, used, and previously used space exists.

 

[DoFoT9]

OK... for us Mac users, there are a couple things to keep in mind:

a) Mac OS is specifically designed to prevent disk fragmentation --- which is effect is the issue at hand for SSD's. They need to first "clear" storage if it was previously occupied and being re-written to.

OSX fragments <20MB files on the fly to ensure that the data is all written in the one "line" to prevent latency etc, but that's not really important for SSDs because of = latency. what about fragmentation for read/writes though? does OSXs "on the fly" fragmentation increase or decrease this performance?

d) Even IF you lost 40% of the performance of your SSD --- and that's a really big if, you would still see a 200 to 300 % increase over a regular mechanical drive.

So, if you find yourself needing to reset your SSD back to fresh fro mthe factory performance.
Step1: use Carbon Copy or Super Duper to create a fill image of it
Step2: Using disk Utility, delete the partition(s) on it
Step3: use Carbon Copy or Super Duper to restore it

The whole process should take about an hour. The reason this works is because removing the partition map, clears the file system "super blocks" which hold the free inode lists --- the codes that says where free, used, and previously used space exists.[/QUOTE]

good tip

ive not yet taken the plunge into the SSD world because i need more storage then speed, so i dont really care. the cost of the SSD isnt enough to justify the speed as of yet. i need multiple TBs of storage not multiple GBs damnit! haha

 

[Libertine Lush]

b) Trim is a device command which would require an OS driver to take advantage of it. Mac OS does not have this, however, the better SSD's have implemented their own form.

What are those other forms better SSDs have called? Garbage collection?

[c) Some vendors have gone even further, OCZ for example, with their garbage collection, spending time with Apple engineers tuning the performance. (OCZ has a Mac edition drive)

I had assumed that the "Mac edition" portion was merely marketing. So is garbage collection the only thing that differentiates the OCZ Mac edition from other OCZ drives? I thought that garbage collection wasn't a feature exclusive to SSDs for the Mac OS.

d) Even IF you lost 40% of the performance of your SSD --- and that's a really big if, you would still see a 200 to 300 % increase over a regular mechanical drive.

I've read of that before, but for the massive price premium we're paying for an SSD, a double digit performance reduction is hard to accept. And even harder when you know that Windows 7 has TRIM to address this issue conveniently.

So, if you find yourself needing to reset your SSD back to fresh fro mthe factory performance.
Step1: ...

Are your instructions any better or easier or faster than the one linked in my initial post:

1. Backup the SSD onto another hard drive. A clone is your best best, and more or less mandatory if the drive is your boot drive.
2. Erase the SSD with Disk Utility. You will need to boot off the clone if the SSD is your boot drive.
3. Write over the entire capacity of the SSD. This can be probably be done successfully with Apple’s Disk Utility (“Erase free space”), but the fastest approach is a tool like DiskTester’s recondition command.
4. Test the speed (DiskTester run-sequential), and repeat step #3 if the speed is not its best.
5. Erase the SSD with Disk Utility again, then clone the backup you made in step 1 onto it. If it’s the boot drive, you can now boot off the reinvigorated drive.
​

Thanks.

 

[solarein]

i wish he explained it a bit more! that doesnt convince me very much. i know he's smart, but yea.. i might just ask nano lol

SSD performance degradation comes from the need to erase blocks on an SSD before data can be written to it. On an HDD you can overwrite blocks without worrying about what's already written in that block. On an SSD, once an NAND cell has been written to, its value cannot be changed unless an expensive erase operation is applied to the entire block to which that cell belongs to reset that entire block to a writable state. Writing 0s to the entire SSD effectively forces the entire SSD into an un-writable state, killing your performance.

A way to reset SSDs that work with some drives is, surprisingly, to write 1s to the entire drive. This is because on MLC NAND, a NAND cell that stores 11 (MLC NAND cells can store two bits) is in fact in the writable state. However, this only works with SSD controllers that keep track of which blocks contain only writable cells. Even if you make all the cells in your SSD writable by writing 1s to the entire drive, if the SSD controller doesn't know which blocks are writable, it will still go through the expensive read-write-erase cycle as if all those writable blocks are unwritable.

So you see how restoring SSD performance is complicated. The data on the SSD itself is not all that matters. What also matters is data the controller stores. The controller stores a block map and keep tracks of free blocks in a separate memory area. This is why methods like secure erase and TRIM work while many others do not work: secure erase and TRIM actually lets the SSD controller know about blocks that can be freed.

 

[mcbridematt]

OK... for us Mac users, there are a couple things to keep in mind:

a) Mac OS is specifically designed to prevent disk fragmentation --- which is effect is the issue at hand for SSD's. They need to first "clear" storage if it was previously occupied and being re-written to.

b) Trim is a device command which would require an OS driver to take advantage of it. Mac OS does not have this, however, the better SSD's have implemented their own form.

c) Some vendors have gone even further, OCZ for example, with their garbage collection, spending time with Apple engineers tuning the performance. (OCZ has a Mac edition drive)

SSD Fragmentation is different from physical hard drive fragmentation. A good SSD tries to do wear levelling - writing data to portions of the flash that are least used - deliberate fragmentation. This is done on a level the OS won't know about
So doing a defrag procedure designed for a spinning disk will just make things worse.

(Remember, NAND flash has to be erased before written)

Writing zeros won't help either, because now you've stored data in every single block, and your drive now thinks every part of flash is used.
The ATA secure erase software mentioned by other posters tells the drive 'forget the data ever existed', so the drive doesn't care about erasing the block before writing it.

I don't have an SSD (yet ), so I'm not sure how one could do it on a Mac. There is a DOS based tool which Intel has recommended to reviewers. The Linux based approach above should work on a Mac.

TRIM isn't necessarily the end all solution either, as the video I will link to below says, it has to be done while the drive isn't doing, or going to do something else. So whatever OS you use may just choose not to do it.

This is a recent talk by Matthew Wilcox of Intel who has been working on the SATA subsystem for Linux, trying to speed it up for SSD's. He describes the workings of SSDs and TRIM in good detail.
ftp://mirror.linux.org.au/pub/linux.conf.au/2010/thursday/50331.ogm (watch in VLC or mplayer)

A bit of google searching turned up OCZ's solution - apart from TRIM, 'garbage collecting' - http://www.ocztechnologyforum.com/f...ne-for-all-does-GC-runs-on-hfs-formatted-disk . Some other SSDs (Samsung I think) actually try and peak at the filesystem map to work out deleted blocks.

 

[Libertine Lush]

A bit of google searching turned up OCZ's solution - apart from TRIM, 'garbage collecting' - http://www.ocztechnologyforum.com/f...ne-for-all-does-GC-runs-on-hfs-formatted-disk .

In that link: "The GC in 1.3 is nowhere near as aggressive as the new FW will be, it may take 24 hours or more of idle time to clean everything up at once."

I had asked previously if garbage collection is any better or worse, or more efficient than TRIM. Judging by that quote, which is written by an OCZ staff member, I assume that garbage collection is, at the least, much slower, as I seem to recall from an AnandTech article some time ago that showed TRIM on one SSD they tested restoring performance within 10 minutes or so.

 

[dclaessen]

Boot from a Linux disc and issue the secure erase ata command from there using 'hdparm'

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

I did exactly this with an Intel X25M 160GB SSD Drive (1st Gen). The drive suffered from stuttering, and my MacBook Pro frequently locked up (beach ball, freezes, hangs) for 20 seconds or more. After doing the reconditioning, the drive runs like fresh (no hangs, freezes or beach balling). Highly recommended for everyone having issues with their drive! The trick is to hot-swap the SSD drive after booting the linux distribution (I used GParted) to get the drive in an unlocked state.

Dennis
p.s. Before this method, i have tried several times to freshly install Snow Leopard (including deleting partitions, formatting etc, but nothing helped).

 

[gotzero]

My "solution" to this is going to be to get new SSDs, since the technology is changing so fast. This is not a long-term solution, but right now, each generation seems to be leapfrogging the last at a much lower price, and I can always use the old ones as scratch discs/storage.

However, so far, I am having no problems with wear, although all of my systems have HDDs to write to.

 

[Macshroomer]

However, so far, I am having no problems with wear, although all of my systems have HDDs to write to.

Same here, I have had my 160 G2 since November and it seems fine, all my data is on a larger HDD. With this in mind, are we dual users that much better off than those who do everything on the SSD?

 

[DoFoT9]

SSD performance degradation comes from the need to erase blocks on an SSD before data can be written to it. On an HDD you can overwrite blocks without worrying about what's already written in that block. On an SSD, once an NAND cell has been written to, its value cannot be changed unless an expensive erase operation is applied to the entire block to which that cell belongs to reset that entire block to a writable state. Writing 0s to the entire SSD effectively forces the entire SSD into an un-writable state, killing your performance.

A way to reset SSDs that work with some drives is, surprisingly, to write 1s to the entire drive. This is because on MLC NAND, a NAND cell that stores 11 (MLC NAND cells can store two bits) is in fact in the writable state. However, this only works with SSD controllers that keep track of which blocks contain only writable cells. Even if you make all the cells in your SSD writable by writing 1s to the entire drive, if the SSD controller doesn't know which blocks are writable, it will still go through the expensive read-write-erase cycle as if all those writable blocks are unwritable.

So you see how restoring SSD performance is complicated. The data on the SSD itself is not all that matters. What also matters is data the controller stores. The controller stores a block map and keep tracks of free blocks in a separate memory area. This is why methods like secure erase and TRIM work while many others do not work: secure erase and TRIM actually lets the SSD controller know about blocks that can be freed.

very nice description there solar, thanks heaps for that!

it seems a bit silly really how the developers of these SSD drives havent taken the re-writing part into consideration (or havent fixed it properly at the lowest level).

how expensive is it to restore the block to a NULL state? couldnt this sort of thing be run in a script at a particular time if a user wants? (maybe at midnight or something)?

you mentioned that setting the MLC drives to 11's sort of NULLs it, but what about SLC drives? is it the same sort of concept? i am assuming not

for MLC NULLs, is it not possible to just update the controller tree map to say which blocks are empty, and which are not? i guess im not really understanding why the whole block HAS to be read/re-written/erased.. might need to research a bit more.

I did exactly this with an Intel X25M 160GB SSD Drive (1st Gen). The drive suffered from stuttering, and my MacBook Pro frequently locked up (beach ball, freezes, hangs) for 20 seconds or more. After doing the reconditioning, the drive runs like fresh (no hangs, freezes or beach balling). Highly recommended for everyone having issues with their drive! The trick is to hot-swap the SSD drive after booting the linux distribution (I used GParted) to get the drive in an unlocked state.

Dennis
p.s. Before this method, i have tried several times to freshly install Snow Leopard (including deleting partitions, formatting etc, but nothing helped).

interseting to know Dennis. thanks for that!

 

[solarein]

it seems a bit silly really how the developers of these SSD drives havent taken the re-writing part into consideration (or havent fixed it properly at the lowest level).

how expensive is it to restore the block to a NULL state? couldnt this sort of thing be run in a script at a particular time if a user wants? (maybe at midnight or something)?

you mentioned that setting the MLC drives to 11's sort of NULLs it, but what about SLC drives? is it the same sort of concept? i am assuming not

The problem with rewriting/erasing is, unfortunately, a technical limitation of SSDs. It's the root of all the potential pitfalls of SSD use. MLC NAND cells can be in one of four states, each a different voltage, allowing it to store 2 bits. Of the four states, one of the states is the default, writable state, and the cell can transition to any of the other three states from this state. This state is commonly associated with storing 11 but this choice is arbitrary and I think you can make a controller interpret this as 00 and it would work too. SLC NAND is similar, except you only have 2 states, 1 of which is the writable state. I'm not sure if with SLC this state is interpreted as 0 or 1. Anyway, if the cell is in one of the unwritable states, the only way to write new data to the cell is to first reset an entire block of cells. This is the technical limitation of current NAND flash technology, where this reset operation can only be addressed to big blocks. Many sources use 512KB as the size of these blocks, but it's unclear to me whether all SSDs use 512KB as the block size, since actual implementations of these things are something of a guarded secret. Another number I've seen for block size is 128KB. In either case, these blocks are very large compared to the size of addressable logical pages for writing to SSDs, which is 4KB. This is where write amplification and the read-write-erase cycle comes from. Lets say that the SSD controller is told to overwrite a 4KB page with data. Since the page had already been written to, the entire 512KB block to which the page belongs has to be reset. But before the reset can happen, the data in the rest of the block has to be read first, and then the entire 512KB block has to be written somewhere else, and finally the old block gets reset. This is a very expensive operation compared to the 4KB the controller was told to do.

for MLC NULLs, is it not possible to just update the controller tree map to say which blocks are empty, and which are not? i guess im not really understanding why the whole block HAS to be read/re-written/erased.. might need to research a bit more.

Yes, this is the whole idea behind TRIM. TRIM tells the controller when a file has been deleted at the file system level, so the controller can have an idea of which blocks can be freed. If it frees these blocks then new writes can come in without needing to go through the read-write-erase cycle. In reality this is quite complicated and there are various combinations of out-of-place writing, wear-leveling, write-amplification, page mapping, and garbage-collection algorithms used by SSDs, which makes the actual writing process not nearly as straightforward as the picture I described above. In reality the read-write-erase cycle may not take place even if the SSD is told to overwrite an already-written page, if the SSD implemented out-of-place writing and garbage collection in a certain way and has some spare area to work with. The situation can be avoided with the right algorithms, but only if the condition allows.

 

[DoFoT9]

this is painting a very nice picture thank you solar!

The problem with rewriting/erasing is, unfortunately, a technical limitation of SSDs. It's the root of all the potential pitfalls of SSD use. MLC NAND cells can be in one of four states, each a different voltage, allowing it to store 2 bits.

so is that actually how the data is stored on the SSD? using voltages of tiny capacitors/etc? im only really familiar with the volatile type of memory storage, still yet to get my head around how it stores it in a non volatile way!

Of the four states, one of the states is the default, writable state, and the cell can transition to any of the other three states from this state.

cell - referring to the smallest possible, lowest level bit storage possible in SSDs? kind of like polarity in mechanical HDDs?

This state is commonly associated with storing 11 but this choice is arbitrary and I think you can make a controller interpret this as 00 and it would work too.

so depending on the controller, is it safe to assume that a 11 might mean that the cell is in a writeable state, 01 might be the equivalent of a "0" bit, 10 might be a "1" bit, and 00 represents cell unwriteable? or something to that accord?

SLC NAND is similar, except you only have 2 states, 1 of which is the writable state. I'm not sure if with SLC this state is interpreted as 0 or 1. Anyway, if the cell is in one of the unwritable states, the only way to write new data to the cell is to first reset an entire block of cells. This is the technical limitation of current NAND flash technology, where this reset operation can only be addressed to big blocks. Many sources use 512KB as the size of these blocks, but it's unclear to me whether all SSDs use 512KB as the block size, since actual implementations of these things are something of a guarded secret. Another number I've seen for block size is 128KB. In either case, these blocks are very large compared to the size of addressable logical pages for writing to SSDs, which is 4KB. This is where write amplification and the read-write-erase cycle comes from. Lets say that the SSD controller is told to overwrite a 4KB page with data. Since the page had already been written to, the entire 512KB block to which the page belongs has to be reset. But before the reset can happen, the data in the rest of the block has to be read first, and then the entire 512KB block has to be written somewhere else, and finally the old block gets reset. This is a very expensive operation compared to the 4KB the controller was told to do.

did i read somewhere that SSDs can use variable block sizes? i can't correctly recall..

that all makes perfect sense and now i understand the term "write-amplification"!

Yes, this is the whole idea behind TRIM. TRIM tells the controller when a file has been deleted at the file system level, so the controller can have an idea of which blocks can be freed. If it frees these blocks then new writes can come in without needing to go through the read-write-erase cycle. In reality this is quite complicated and there are various combinations of out-of-place writing, wear-leveling, write-amplification, page mapping, and garbage-collection algorithms used by SSDs, which makes the actual writing process not nearly as straightforward as the picture I described above. In reality the read-write-erase cycle may not take place even if the SSD is told to overwrite an already-written page, if the SSD implemented out-of-place writing and garbage collection in a certain way and has some spare area to work with. The situation can be avoided with the right algorithms, but only if the condition allows.

very complicated stuff, but im getting the gist of it. keeping a running tab on everything would be hard, especially with the fact that the block sizes of data (512KB etc) are MASSIVE compared to the capabilities of the controller (4KB etc).

interesting stuff.

 

[Libertine Lush]

c) Some vendors have gone even further, OCZ for example, with their garbage collection, spending time with Apple engineers tuning the performance. (OCZ has a Mac edition drive)

I just stumbled across the answer to my question about that statement. I had said, "I had assumed that the "Mac edition" portion was merely marketing. So is garbage collection the only thing that differentiates the OCZ Mac edition from other OCZ drives? I thought that garbage collection wasn't a feature exclusive to SSDs for the Mac OS."

From AnandTech, referring to OCZ: "There’s a Mac Edition of the Vertex, unfortunately it’s no different than the regular drive - it just has a different sticker on it and a higher pricetag."

http://www.anandtech.com/show/2829/12

 

[Maximus434]

I just stumbled across the answer to my question about that statement. I had said, "I had assumed that the "Mac edition" portion was merely marketing. So is garbage collection the only thing that differentiates the OCZ Mac edition from other OCZ drives? I thought that garbage collection wasn't a feature exclusive to SSDs for the Mac OS."

From AnandTech, referring to OCZ: "There’s a Mac Edition of the Vertex, unfortunately it’s no different than the regular drive - it just has a different sticker on it and a higher pricetag."

http://www.anandtech.com/show/2829/12

Anandtech is right, there's no difference, just the name.

I have an OCZ vertex 120GB and it screams (well it did before I sold my MBP!).

The vertex has 1.5 firmware which is more agressive with garbage collection. It maintains the drive at it's top speed by basically restoring all the empty space to optimum.

You are worrying about nothing. Vertex with 1.5 is as good as TRIM, the drive looks after itself regardless of what OS you use it on. Besides, even if it DIDN'T have garbage collection, the speed degredation in a full drive is unnoticable. I was still getting 120+Mbps sequential read/write speeds on a 1.5GB sata controller. I only ever saw a 4 or 5 mb/s drop with a used drive before I installed 1.5 firmware. Unnoticable.

 

[J&JPolangin]

...so what's the best way to clean up my Intel G2 80Gb SSD that I planned to put into my whitebook?

It almost sounds like restoring to a fresh formatted drive from a recent back up is the way to go?

 

[DoFoT9]

...so what's the best way to clean up my Intel G2 80Gb SSD that I planned to put into my whitebook?

It almost sounds like restoring to a fresh formatted drive from a recent back up is the way to go?

pretty much yup that will work fine for ya

 

[J&JPolangin]

pretty much yup that will work fine for ya

...how often should you need to "clean up" an SSD running in OSX?

What's the best way to see if there is really any noticeable slowdown?

 

[DoFoT9]

...how often should you need to "clean up" an SSD running in OSX?

depends on how much of the 80GB you are using. how much would you be using? if your using 40GB of it, probably once every 6 months. it depends on your usage.

What's the best way to see if there is really any noticeable slowdown?

the most noticeable slow downs will be from launching applications, or swapping RAM->Virtual memory when opening up a Virtual Machine via parallels/vmware etc. the best way would be to launch an application when you first install the SSD, count how many times it bounces before it loads. then in a month or so try again, and so on. when your fed up of the load time-do a reinstall.

 

[J&JPolangin]

depends on how much of the 80GB you are using. how much would you be using? if your using 40GB of it, probably once every 6 months. it depends on your usage.

I've got it down to ~60 Gb of files and OS I want to use and the original 320 Gb HDD will be in an external enclosure to use as a back up and the rest of the files I didn't routinely need on the SSD...

[/QUOTE]the most noticeable slow downs will be from launching applications, or swapping RAM->Virtual memory when opening up a Virtual Machine via parallels/vmware etc. the best way would be to launch an application when you first install the SSD, count how many times it bounces before it loads. then in a month or so try again, and so on. when your fed up of the load time-do a reinstall.[/QUOTE]

...ok

 

[DoFoT9]

I've got it down to ~60 Gb of files and OS I want to use and the original 320 Gb HDD will be in an external enclosure to use as a back up and the rest of the files I didn't routinely need on the SSD...

hmm ok thats not too bad! it will be pretty full though so the 80GB will be accessed more then if you were to go for a 128GB etc. meaning you may have to format a bit more often, it all has to do with how much u want to do it though

...ok

make sense lol?