Linux Solid-State Drive Benchmarks

[curaga]

I believe it's not possible to bypass the inbuilt algorithms of SSDs. But it would be an interesting read to see how an SSD with it's own logic and some fs on top of it stacks against the same flash chip, but with the MTD layer and JFFS2 handling the wear levelling.

[Svartalf]

Like the db firefox uses ?

DB? It's an http/html client. If it uses a DB, it's not in the same manner as oracle and it's not CONSTANTLY using it.

Or your IM client?

Uh, an IM client logs a constant slow stream to the same place and puts things to the display. NOT random operations. Sorry.

Or those config files that are read by the thousand when you computer starts?

Linear stream. NOT random accesses. Begin to see a pattern here?

Or all those icons?

Again, done largely once and NOT random access. I think you're going to find that the random writes are the problem with any SSD with "issues", NOT really the read operations.

Or the small files in the latest update to your favorite package?

How many, what size, how often. I think you're blowing this more out of proportion than it needs to be- you're exaggerating everything here to try to make a point. Unfortunately for you, I'm versed on things like performance of disks (including SSDs) because I have to be to max out performance of things like network monitoring probes and deep packet inspection engines for my day job. The stuff you're bringing up isn't IN the use cases normally- just like I said.

Or those small blocks bittorrent clients save and retrieve at a time?

This might be the case, but honestly, HOW many people that're in that market segment using laptops would be bittorrenting things?

Or those swap files when you don't have that much ram?

Of the examples you give, the ONLY one that matches up with their envisioned customer market would be THIS one. Everything else doesn't work.

Or all those thumbnails when you're previewing your photos?

Typically, you thumbnail once on the main UI. Inside an app, you don't thumbnail to disk.

I think manufacturers shot for "very pretty benchmark values" and forgot to do their homework. I think small reads and writes is one of the main workloads of most computers, but they have been forgotten.

Actually, it's a big mix of both types of operations, based on my 30 years as an enthusiast and 25 years as a professional developer. They missed their homework just a bit (and it shows on some of them- and I believe I pinned why the random write problem is there...), but apparently so did you. Next time, I suggest you contemplate what actually gets done repeatedly and often- you only had ONE of all of that list as actual issues with the random write performance for an average user (You aren't, neither am I- and bittorrent, while it's the other one that's "valid", isn't being used as much unless you're talking someone playing World of Warcrack which uses it to push updates more efficiently, you've got someone getting Linux distro ISOs, or doing warez...)

[Svartalf]

I believe it's not possible to bypass the inbuilt algorithms of SSDs. But it would be an interesting read to see how an SSD with it's own logic and some fs on top of it stacks against the same flash chip, but with the MTD layer and JFFS2 handling the wear levelling.

JFFS2 isn't the sharpest tool in the shed performance-wise. The compression and journalling will slow you down more than the chips' weak wear levelling performance will.

[edgar_wibeau]

Svartalf, as I wrote above, I had a 32GB first generation MLC SSD in use which was slow on linear read/write yes (like 30/20 MB/s), but the major bottleneck even for desktop usage was the random write rate here. Problems were (unexpected to me) firefox usage which froze for some seconds regularly even though I had disabled its disk cache, a major problem were big debian (or did I use ubuntu?) uptdates where a 500 package upgrade (after download) took a whole night (8 hours) instead of maybe half to one our using a normal (not fast ~40 MB/s) notebook disk.

So I can at least confirm some of Knuckles' claims. Random reads are not the problem with any SSD I saw so far though - your point.

Regarding random writes, I got values ranging from 90 to 300 ops per second (depending on how I measured, block size was 4k)* using the Mtron 3525 SLC SSD on an Atom N270 EeeBox B202 which also is not blazingly fast, yet fast enough for desktop usage. The brilliant thing are random reads, exceeding 10k/s upto more than 20k/s which makes this little guy kick any spinning disk where nobody wants to be kicked

* Linus claims 8500 writes/s using 4k blocks for the Intel MLC SSD here (7th paragraph). Now this would really be amazingly fast! I'd really like to know how the other 3rd gen MLC SSDs like the OCZ Vertex will perform.

[BlackStar]

Like the db firefox uses ?

DB? It's an http/html client. If it uses a DB, it's not in the same manner as oracle and it's not CONSTANTLY using it.

Firefox 3 uses an sqlite database to track bookmarks, browsing history and power its address bar. Yes, this entails many random reads and writes and yes it's *painful* on 1st-gen SSDs.

Uh, an IM client logs a constant slow stream to the same place and puts things to the display. NOT random operations. Sorry.

Linear stream. NOT random accesses. Begin to see a pattern here?

By itself the IM client may not be a problem, but try having a conversation while upgrading a package. Latency becomes a significant issue and the whole IM becomes unresponsive (talking about Pidgin here).

The point you are missing is that while most desktop programs use the drive more or less linearly, you typically run more than one program at once. Latency is a real issue that renders (current and previous) cheap SSDs, USB sticks etc unsuitable for day to day usage. To give you an example, the original OCZ Core drive drops down to *4* ops per second on random writes - not nearly enough!

If you wish to see this effect for yourself, try the Ubuntu LiveUSB on a 2GB usb stick with read/write support. Reads are plenty fast (Firefox launches instantly!) but writes make the system quite unresponsive.

Edit: From Linus' blog:

And the sad part is that other SSD's generally absolutely suck when it comes to especially random write performance. And small random writes is what you get when you update various filesystem meta-data on any normal filesystem, so it really does matter. For example, a vendor who shall remain nameless has an SSD disk out there that they were also hawking at the Kernel Summit, and while they get fine throughput (something like 50+MB/s on big contiguous writes), they benchmark a pitiful 10 (yes, that's ten, as in "how many fingers do you have) small random writes per second. That is slower than a rotational disk.

[Nexus6]

I'd really like to see some benchmarks for SATA vs SSDs being used as swap partitions. I've often wondered whether there would be any benefit to using SSDs (or even memory sticks/SD cards) for swap.

[[Knuckles]]

I'd really like to see some benchmarks for SATA vs SSDs being used as swap partitions. I've often wondered whether there would be any benefit to using SSDs (or even memory sticks/SD cards) for swap.

+1 i've wondered about this myself too.

@Svartalf: both firefox and my IM client like to use a lot of sqlite. Already two "apps" in kde 4 (amarok and akonadi [not really an app, used by many apps]) use mysql.
I think Blackstar's answer already covered it pretty well too. You are free to disagree of course

[curaga]

Memory sticks and SD cards would die quickly from using swap.. BTW why does this not affect SSD's? Or does it, but they just have higher quality flash chips, and so can withstand more write cycles?

[BlackStar]

That and they also implement wear-leveling logic, where the drive tries to spread writes evenly to avoid wearing out the same cells.

That said, I'm still not convinced that this is a real problem. Someone tried to kill USB sticks by writing data non-stop for *months* and they didn't fail (sorry, don't have the link). All things considered, SSDs are far more reliable than rotating glass disks, moving needles and oil-leaking motors.

Posting with Archlinux on a 8GB usb stick

[edgar_wibeau]

BlackStar: The ones trying to kill the USB stick are german c't magazine (http://www.heise.de/ct/), they are using a small (2GB IIRC) but fast USB stick. Small and fast so that their chance is higher to really wreck that stick. Their test is indeed running for months now, I haven't tried to find anything online though, because I read ebaout it twice in the paper issue. To all who don't know: c't magazine is a VERY believable source. They use to point their fingers on stuff no other IT magazine (online nor offline) ever touches.