From our front-page news:
It's been exactly two weeks since I last reported on my investigations into TRIM for Linux, so now seems like a great time to update you all on my progress. Unfortunately, because I've been focusing so much on our regular content, I haven't been able to dedicate as much time to testing things out as much as I'd like, but I have made a few strides and feel like I should have a complete answer to the situation soon.
The first problem I had to tackle seems simple. I had to figure out how to benchmark a storage device under Linux and get reliable results out of it. In Windows, there's a variety of applications to use, such as HD Tune, HD Tach, PCMark Vantage and so forth, but there's little choice under Linux, and of what there is, it's all command-line-based. After fiddling around for hours on end, I settled on iozone. I chose it because it's one of the easiest to use, and also one of the most configurable. Plus, it gave me reliable results, which is of obvious importance.
To benchmark a drive, I have iozone create a 16GB file to work with (the recommended value is 'system RAM * 2'), and allow it use data chunks ranging between 4KB and 1MB. The exact syntax I'm using is below:
iozone -a -f /mnt/ssdtest/iozone -i0 -i1 -y 4K -q 1M -s 16G
On a 100% clean Kingston SSDNow M Series 80GB (G1, no TRIM support) formatted as ext4, the 4K write speed was 86.55MB/s, while the read speed was 229.70MB/s. Given that these are close to the rated specs of the drive (officially, it's 250MB/s read and 70MB/s write, but Intel's drives have always written at higher-than-rated speeds), I feel confident in the results. So with the benchmarking solution squared away, the next chore was to figure out how to see if TRIM was indeed working or not. That of course required figuring out a scheme to properly "dirty" a drive.
In our look at Intel's SSD Toolbox and TRIM solution back in October, I mentioned that due to Intel's excellent algorithms in place, its drives are very complicated to dirty. As I found out over the past few days, the real issue was me, and not thinking about the mechanics of it all enough. To dirty the drive before, I simply allowed Iometer to create a file as large as the drive itself, and then re-ran the same test over and over until I was satisfied. Looking back, I can't help but wonder what I was thinking, because when looking at the reason drives get dirtied, I could have solved my own predicament.
To effectively dirty an SSD, you need files, and lots of them. To make things easier with testing, I've been using the drives in my own machine, and because of this, my personal files were handy. So, with the 80GB G1 installed, I wrote a quick script to copy over my entire /documents/ folder (~74GB, 43,000 files), delete it, and then copy over three other folders (~64GB, 149,982 files), and then delete them. Rinse and repeat just once, and the result is one heck of a dirtied drive.
While the performance beforehand was roughly 230MB/s read and 86MB/s write, the results after the dirtying was 198.73MB/s read and 23.33MB/s write. Yes, that was on am "emptied" drive. The way I dirtied the drive may be a tad unreliastic, as I truly barraged the SSD with a total of almost 400,000 files, but as long as I had a dirtied drive, I was pleased. Now that I understand both the mechanics of benchmarking the drive, and also dirtying it, I'm going to install the 160GB G2 drive today and begin testing for TRIM. As it stands, I have no idea whatsoever if it's going to work right out of the box, and deep-down, I don't expect it to. Given where I am in testing now, though, I expect to have a real answer sometime next week, so stay tuned.
The first problem I had to tackle seems simple. I had to figure out how to benchmark a storage device under Linux and get reliable results out of it. In Windows, there's a variety of applications to use, such as HD Tune, HD Tach, PCMark Vantage and so forth, but there's little choice under Linux, and of what there is, it's all command-line-based. After fiddling around for hours on end, I settled on iozone. I chose it because it's one of the easiest to use, and also one of the most configurable. Plus, it gave me reliable results, which is of obvious importance.
To benchmark a drive, I have iozone create a 16GB file to work with (the recommended value is 'system RAM * 2'), and allow it use data chunks ranging between 4KB and 1MB. The exact syntax I'm using is below:
iozone -a -f /mnt/ssdtest/iozone -i0 -i1 -y 4K -q 1M -s 16G
On a 100% clean Kingston SSDNow M Series 80GB (G1, no TRIM support) formatted as ext4, the 4K write speed was 86.55MB/s, while the read speed was 229.70MB/s. Given that these are close to the rated specs of the drive (officially, it's 250MB/s read and 70MB/s write, but Intel's drives have always written at higher-than-rated speeds), I feel confident in the results. So with the benchmarking solution squared away, the next chore was to figure out how to see if TRIM was indeed working or not. That of course required figuring out a scheme to properly "dirty" a drive.
In our look at Intel's SSD Toolbox and TRIM solution back in October, I mentioned that due to Intel's excellent algorithms in place, its drives are very complicated to dirty. As I found out over the past few days, the real issue was me, and not thinking about the mechanics of it all enough. To dirty the drive before, I simply allowed Iometer to create a file as large as the drive itself, and then re-ran the same test over and over until I was satisfied. Looking back, I can't help but wonder what I was thinking, because when looking at the reason drives get dirtied, I could have solved my own predicament.
To effectively dirty an SSD, you need files, and lots of them. To make things easier with testing, I've been using the drives in my own machine, and because of this, my personal files were handy. So, with the 80GB G1 installed, I wrote a quick script to copy over my entire /documents/ folder (~74GB, 43,000 files), delete it, and then copy over three other folders (~64GB, 149,982 files), and then delete them. Rinse and repeat just once, and the result is one heck of a dirtied drive.
While the performance beforehand was roughly 230MB/s read and 86MB/s write, the results after the dirtying was 198.73MB/s read and 23.33MB/s write. Yes, that was on am "emptied" drive. The way I dirtied the drive may be a tad unreliastic, as I truly barraged the SSD with a total of almost 400,000 files, but as long as I had a dirtied drive, I was pleased. Now that I understand both the mechanics of benchmarking the drive, and also dirtying it, I'm going to install the 160GB G2 drive today and begin testing for TRIM. As it stands, I have no idea whatsoever if it's going to work right out of the box, and deep-down, I don't expect it to. Given where I am in testing now, though, I expect to have a real answer sometime next week, so stay tuned.
