Comments for SSD Performance Blog

Comment on Intel 320 SSD write performance – contd. by John Laur

John Laur — Mon, 23 Jan 2012 21:17:12 +0000

The GC algorithm can only erase blocks it are very sure do not contain data. How can it know this? Well, if a block is completely zeroed it might have a clue; or it can know something about the filesystem. Does Intel’s GC algorithm know about NTFS? Probably. How about Ext4? Maybe. How about XFS? Doubtful. But how can we know and plan for this when the algorithms is not well documented?

When the drive is formatted only a small space of data is changed. To the SSD controller the drive is still full of blocks of allocated data from the previous run, so it’s not surprising in the least to see this behavior. The filesystem may not allocate files into exactly the same blocks on the second run as it did the first, so the amount of “free” erased blocks that the SSD can use for performance advantage is reduced. But by secure erasing and repartitioning with a smaller partition size you can ensure that a certain fixed set of blocks are never written at all. This in effect gives the user the ability to tune the reserved allocation of flash and limit the effect of the ‘write wall’ that is so well documented here. In fact, simply keeping your filesystem X% full may not be enough (and without a driver, controller, disk, etc. that supports TRIM all the way down the stack it will never be enough) – artificially limiting the partition size (or volume size on a RAID array) in this manner will be necessary.

You also have to be very careful if you are building arrays with SSD as the build algorithm will have a tendency to write blocks to a large portion of each drive. (Raid-1 silver will “fill” a SSD) So the real solution is to be able to tune the amount of reserved flash on the hardware (iodrive) or at least be able to purchase drives with more native reserved space (most Sandforce drives).

Comment on MLC SSD card lifetime and write amplification by Vadim Tkachenko

Vadim Tkachenko — Sat, 07 Jan 2012 03:19:30 +0000

I do not have link on the hand right now, but I remember I saw 8PB lifetime for FusionIO cards.

Comment on MLC SSD card lifetime and write amplification by alec matusis

alec matusis — Sat, 07 Jan 2012 03:17:36 +0000

I cannot find lifetime write allowance for FusionIO duo MLC cards. From what their sales rep told us, it’s 2x the card capacity daily writes for 10 years. Is this spec available anywhere?

Comment on MLC SSD card lifetime and write amplification by Phil Robins

Phil Robins — Wed, 04 Jan 2012 21:13:43 +0000

I think that even in most production environments – 1125GB per hour 24/7 is way beyond most applications – many systems are read heavy as opposed to write. Of course the trick is to only use MLC in such environments where such heavy writes would not occur.

Comment on Intel 320 SSD read performance by brade

brade — Fri, 16 Dec 2011 22:53:32 +0000

I just compiled latest version from scm and working like a charm.

Comment on Intel 320 SSD read performance by brade

brade — Fri, 16 Dec 2011 15:44:45 +0000

Hi Vadim!

im trying to run yours scripts and looks like i don’t have report-interval param in my latest sysbench version:

sysbench --report-interval Unknown option: --report-interval.

sysbench --version sysbench 0.4.12

are you using official release version?

Comment on MLC SSD card lifetime and write amplification by malkor13

malkor13 — Thu, 01 Dec 2011 09:01:09 +0000

Great article, makes you think if SSD really worth it in production enviroment…
Surely the price is not there yet…I will assume that the disk you have tested should last about 2-3 years on medium workload..

Comment on Intel 320 SSD write performance – contd. by comparador de precios

comparador de precios — Tue, 08 Nov 2011 10:45:35 +0000

Can you do same with btrfs and tmpfs?

Comment on Intel 320 SSD write performance – contd. by Vadim Tkachenko

Vadim Tkachenko — Mon, 17 Oct 2011 20:39:45 +0000

Will,

I did not try that, I may do in next round of benchmarks.

However that fact that performance degrades overtime it is the fact,
I see in many MySQL benchmarks.

Comment on Intel 320 SSD write performance – contd. by Will Smith

Will Smith — Mon, 17 Oct 2011 20:01:10 +0000

Have you tried varying the amount of time between 1st and 2nd runs?

My hypothesis is that the SSD needs time to “recover” i.e. the garbage collection is running at low priority and only does its thing when you give the SSD a “pause”.

Maybe there’s justification for leaving servers on overnight, or even, in extreme production environments, having a live-SSD and a recovering-SSD and alternating (perhaps each day?)