[O/C]SSDs, TRIM, and Available Disk Space

SSDs, TRIM, and Available Disk Space
by I.M.O.G.

There is a lot of discussion on forums about the impact of available disk space on SSD performance. A pertinent question was raised; At what point does drive utilization impact SSD performance? Running some quick tests, the results proved rather insightful.

Questions and Answers

Earthdog raised that question in this post on Overclockers Forums. It spawned from the prevailing knowledge professed across forum communities reporting that available disk space has rather relevant impact upon the performance one obtains from an SSD. There is considerable evidence supporting that stance also.

Click to expand...

Click here to continue reading.


Discuss this article below. If you are interested in contributing to the front page (www.overclockers.com), please feel free to contact splat, mdcomp, or hokiealumnus.

Thank! Good article.

Interesting article. I wonder if you wouldn't see bigger differences with random writes.

I wonder also. I've installed and am evaluating sysbench currently - its designed for benchmarking database performance, but it does random I/O testing on linux so it may suit our interests.

EDIT: To answer your question, preliminary testing gives no indication that the results are any different with random write performance, in relation to available disk space.

Preliminary random write performance testing using sysbench at 63.9% capacity:

Operations performed: 0 Read, 10000 Write, 12800 Other = 22800 Total
Read 0b Written 39.062Mb Total transferred 39.062Mb (1.3073Mb/sec)
334.67 Requests/sec executed

Test execution summary:
total time: 29.8797s
total number of events: 10000
total time taken by event execution: 0.0755

Click to expand...

Preliminary random write performance testing using sysbench at 83.5% capacity:

Operations performed: 0 Read, 10000 Write, 12800 Other = 22800 Total
Read 0b Written 39.062Mb Total transferred 39.062Mb (1.3266Mb/sec)
339.60 Requests/sec executed

Test execution summary:
total time: 29.4464s
total number of events: 10000
total time taken by event execution: 0.0778

Click to expand...

These followup tests were performed with the following command:

So you have tested Sequential and Random writes/reads apparently.

One thing I have wondered is how the drives stack up to true 'multi-tasking' like a mechanical drive..... how fast is it while reading/writing at hte same time?

Thanks IMOG! Question then for my simple mind

I got one of the Intel 40 gig SSDs that was on sale middle of Jan. W7 sets it up, diabling Defrag, Trim is okay I guess.

I use it as a boot drive. I have 11.5 GB free, is that enuff for allowing room to do it's thing? What do you think is the min empty area for all the goodness to continue?

I can't say really, these tests imply available space doesn't have noticeable impact. Under different conditions, maybe it does... I still haven't gotten around to loading windows 7 and running a more thorough gambit of tests. When I get that done, and the article is published, I'll have more to say which will be useful for people in your situation.

You also said "trim is okay I guess", you can issue this command from the command prompt:
fsutil behavior query DisableDeleteNotify

If disabledeletenotify comes back as 0, then trim is enabled and recognized correctly by your OS.

Yep, I'm Trim enabled, thanks.

Perhaps I'm wrong.

I'm just not getting it. If Trim has been run on the drive then it really shouldn't matter how much space is being used. All the free space would be available to be written to. Isn't that the idea of Trim? (I haven't done much research, but that is the take away I get from this article.)

Now on an SSD that isn't using Trim I could see issues as the free space decreases. I would think the same thing would also apply to a drive that is written to heavily regardless of free space...

I'm looking forward to the rest of the testing.

That's what the results suggest, that if Trim has been run it doesn't matter how much free space is available when the test is run. However, in real life daily usage people report better performance with more free space available, and they're making configuration changes to leverage that.

I.M.O.G. said:

That's what the results suggest, that if Trim has been run it doesn't matter how much free space is available when the test is run. However, in real life daily usage people report better performance with more free space available, and they're making configuration changes to leverage that.

Click to expand...

Well kinda, TRIM alleviates the issue, but does not completely solve it on its own. Over provisioning the flash and data compression also help. I would guess the Vertex 2 Pro and other Sandforce controller based SSDs with the combination of TRIM, heavy over-provisioning and data compression have this problem solved.

As I understand it the issue stems from how data is written to flash and the fact that you can't overwrite data on flash. Writing a piece of data to a flash block is simple, you just write it to a page on the block. Writing another piece is as simple. Just write to another page in the block. But modifying a piece of data is more complicated. Since you can't overwrite the data what the controller does is that it writes the modified data to a new page in the block and marks the old page as invalid. When the block starts to fill up with data garbage collection happens. The controller, in the background, writes the valida data to a new block and wipes the old one.

The performance problem from having full SSDs is that when the blocks are kinda full with valid data only a little modifying of data on the block will mean that it is filled up by the extra invalid pages and forcing GC to run. With a really full drive you are forced to run GC almost constantly resulting in a performance drop.

What TRIM does to help is that without TRIM even deleted data will look like valid data to the SSD controller, meaning the the amount of what the SSD thinks is valid data is much higher than what the OS reports. TRIM tells the SSD controller that the deleted data is invalid and so lets it wipe it out in GC.

You can still get the performance drop even with TRIM by just really filling up the SSD. Also the type of writes you do. Lots of small write will produce fragmentation which exacerbates the issue. Since you are TRIMing you might not be filling the drive up enough. You would probably have to go over 90% full to see the effect. You also need to be modifying the data to get the problem.


P.S. The GC I am talking about is not the same GC that is an alternative to TRIM people usually talk about when referring to SSD.

P.P.S. Because the Indilinx controller uses a largely static LBS mapping it only uses the over-provisioned flash as scratch-pad, while the Intel controller uses all empty flash blocks. This gives the Intel controller extra performance from having lots of empty flash blocks the the Indilinx controller doesn't get. Conversely the Intel controller has form of performance drop from filling up that the Indilinx controller doesn't suffer from.

P.P.P.S. Having lots of empty space also helps with write-leveling since the controller has a bigger chance of finding a flash page that has been written relatively little to to write on.

OCZ released version 1.5 of the firmware which supports both TRIM and GC without requiring different versions. You may want to run your tests again.

Yes, I have it loaded, and it might be interesting to see the tests run again. Time lately has been crunched from work, and I somewhat place the Windows7 tests in regards to capacity as a higher priority. But, it's on my "want to do" list. Thx for the heads up.