SSD Linux reviews

[thanosz]

Hi,

I would like to ask if there are any plans to include Linux tests in SSD reviews. It would be good to test not only the performance of a specific SSD but also how well the drive works in Linux (out of the box with existing firmware) and what steps may be required to get optimal performance (TRIM support, correct partition alignment).

Thanks.

 

[Kougar]

Howdy Thanosz, and thanks for your comment! Are there any programs or tests in particular you would be interested in seeing?

The largest problem with adding Linux is that I am outside my area of expertise and generally have trouble with just simple tasks in Linux. There aren't any Linux-based programs other than possibly GIMP that immediately spring to mind as test candidates, as I do most of my work within Windows.

The other issue is that currently I am not aware of any Linux distros that support TRIM natively. There are a few Linux programs that can let you manually TRIM an SSD, but that's it so far. If you use Linux on an SSD you can find some tools in the stickies here: Link

There is a new file system for Linux being developed (Btrfs), however while it supports SSDs I can't completely confirm it implements TRIM directly yet.

 

[Glider]

TRIM is integrated in the Linux Kernel since 2.6.33, no tools are needed...

http://en.wikipedia.org/wiki/TRIM

 

[Rob Williams]

TRIM is integrated in the Linux Kernel since 2.6.33, no tools are needed...

The thing is, though... does it just work? There's so little information to go on. I did find traces of it in more than one file from the 2.6.33 source code, though:

drivers/ata/libata-scsi.c:      case WRITE_SAME_16:
drivers/scsi/sd.c:              rq->cmd[0] = WRITE_SAME_16;
drivers/scsi/scsi_debug.c:      case WRITE_SAME_16:
drivers/scsi/scsi_debug.c:      case WRITE_SAME_16:
include/scsi/scsi.h:#define WRITE_SAME_16             0x93

The code for the first file does state that if the proper command is sent, it's executed (0x93), but even so, there are other variables to consider. Does TRIM work on just the OS drive, or all other drives installed? How can you even check to make sure that TRIM is working and enabled?

About half a year ago abouts, I wrote an Iozone script that did a great job of dirtying a TRIM-enabled SSD, but I found out quick that Intel's firmware for garbage collection is good, so it was very difficult to see a real before and after result. TRIM at that time wasn't working, and I still couldn't get a truly definitive answer.

I've been putting off installing an 80GB Intel G2 SSD for a while, so this might be a good reason to get it installed and begin testing, and to see whether or not TRIM is actually working or not. If I have any doubt that the SSD isn't dirtied enough, I might just boot up with an Ubuntu live CD and test there as well, since it won't support TRIM.

 

[Rob Williams]

I had been hoping that the HDD benchmarking tool included in GNOME would be good enough to benchmark with... but I don't think so. I ran it on a netbook here, which is using an Intel 80GB G1, and the results are even better than the official specs!

 

[Rob Williams]

I decided to get down to testing the other night, on both a non-TRIM and TRIM drive. But at this point, I'm thinking that I need to find a new method of dirtying a drive, because based on the results, what I'm doing is not effective enough. For the sake of it being configurable, I've been using Iozone, using this command:

iozone -a -i 0 -i 1 -n 16G -g 16G -q 4k -f /mnt/ssdtest/

What this does is create a 16GB file on the drive, and uses it for the sake of testing. The file has to be so large because otherwise, it would use the available RAM. Choosing 16GB makes sure there's no chance of that happening, since it would skew the results otherwise.

To dirty the drives, I ran a script that copied over enough data to 100% fill the drive. This data consisted of 590,519 files and 48,603 folders. Once done, it purged all the data, and then rinsed and repeated for a total of ten rounds.

Here are the results:

Kingston SSDNow M Series 80GB (TRIM)

Clean Run #1: 92.46MB/s Write | 229.78MB/s Read
Clean Run #2: 93.18MB/s Write | 228.63MB/s Read
Clean Run #3: 93.36MB/s Write | 229.06MB/s Read

Dirty Run #1: 85.21MB/s Write | 248.17MB/s Read
Dirty Run #2: 83.89MB/s Write | 254.44MB/s Read
Dirty Run #3: 84.01MB/s Write | 248.79MB/s Read

Kingston SSDNow M Series 80GB (non-TRIM)

Clean Run #1: 93.23MB/s Write | 251.48MB/s Read
Clean Run #2: 93.08MB/s Write | 238.98MB/s Read
Clean Run #3: 94.03MB/s Write | 237.55MB/s Read

Dirty Run #1: 91.51MB/s Write | 255.28MB/s Read
Dirty Run #2: 87.71MB/s Write | 256.24MB/s Read
Dirty Run #3: 83.01MB/s Write | 252.43MB/s Read

I should note that the "Clean" drives were made clean with the help of HDD Erase's Secure Erase feature, restoring them to a factory condition. Also, some of these results might vary a bit more than they should because I was actually using the PC as normal. I didn't touch the drive outside of benchmarking, but I did have a lot going, including a virtual machine.

Interestingly, on both the G1 and G2, I saw 90MB/s+ write speeds, even though the drive is specced for 80MB/s. Also interesting is that on the clean drives, the read speeds are lower than expected.

Then moving over to the dirty drives, the write performance went back to "normal" on both drives after a couple of runs, and the read speeds also evened back out where they should be. Roughly, the third run on each drive delivered results on par with a brand-new drive, so in effect, there was no real gain from TRIM if it was indeed working, because the drives simply were not dirtied enough.

It's almost like I need to find an SSD with a poor algorithm just to figure out if TRIM is working or not :-|

 

[Glider]

You can check with hdparm IIRC... And it will just work. If you understand how the Linux FS works (With the VFS) it wouldn't make sense not to work everywhere...

 

[Rob Williams]

I tried numerous ways to check for TRIM with hdparm and couldn't find a single thing. I'll check later to see if the wiper.sh tool has been modified to work with more than just OCZ drives and see if it works. Although that's not the problem per se, since it's TRIM from the kernel I'm looking to get functioning.