Hacker News Reader

Comment by AngryParsley | Hacker News Reader

One thing the article didn't address is performance over time. Even with TRIM support, SSDs get slower as they're used. Occasionally, cells die prematurely causing spare capacity to decrease. This won't affect read speeds much but it will hurt writes. These older SSDs will still be faster than hard drives but they won't be as fast as you'd expect them to be.

Now for some of my own data. Here's an Intel X25-M G2 after a lot of usage: http://abughrai.be/pics/ssd_erase/Screenshot-160%20GB%20Soli... and here it is after an ATA secure erase: http://abughrai.be/pics/ssd_erase/Screenshot-160%20GB%20Soli...

The G2 has TRIM support and this drive was used on an ext4 filesystem with TRIM enabled. After the erase, performance was almost back to that of a pristine drive. There was a 6GB swap partition on the drive as well as the ext4 partition. I'm pretty sure swap partitions aren't trimmed, so that could have been the reason for the performance degradation.

View on HN

I agree completely that, even with TRIM, the benchmarked performance of an SSD decreases over time. However, one thing to remember is that the real-world performance remains very similar, and that the average person won't be able to tell the difference. I recently had two identical Macbook Pro's next to each other, one with a Intel X25-M G1 drive in it that had been used for nearly 18 months, and the second with a fresh out the box X25-M G2. Even taking into account the fact that the G2 was factory fresh, and the G1 (a drive that does not support TRIM) was significantly slower benchmark wise, the experience of using the two machines was almost identical. There were differences, but they were very slight. I doubt I could have reliably picked which was which in a double blind test.

So for desktop use, I wouldn't worry about the performance over time of a good SSD.

The kernel should really issue a large TRIM for most of the swap partition at swapon time.

...and in fact, it does so: http://lxr.linux.no/#linux+v3.0/mm/swapfile.c#L2117 (and has since kernel 2.6.29).

Additionally, if you set the SWAP_FLAG_DISCARD flag to swapon(2), it'll issue TRIMs for swap space that is freed at runtime. You'll need a pretty recent /sbin/swapon to support that flag, though.

Once upon a time, it was best practice to keep the swap file/partition (or log files, etc.) off of the SSD in order to keep the frequent writes from wearing out the SSD too quickly. Do you feel like this is outdated advice?

Certainly putting the swap not as a partition but as a file on the filesystem will help with TRIM and maybe even wear leveling.

It won't make a difference - in both cases, the swap code accesses the underlying block device directly, and is responsible for TRIM. (The swap code does issue TRIMs though, since kernel 2.6.29).

What would you define as a lot of usage?

I'd say it got about 5GB/day of mostly-sequential writes for a year, and I base that on absolutely no quantifiable data. It was used for lots of development; compiling stuff, running an IDE and browser in addition to the full stack of stuff in production. It had MySQL with a prod snapshot, RabbitMQ, a Django web app and a bunch of twisted services. The biggest writing culprits were restoring MySQL snapshots and ridiculously verbose logging from services.

Most raid controllers don't support TRIM on arrays. Were you using a raid set perhaps?

Reply on news.ycombinator.com