Tweaking Solid State Drive Performance On Linux

perlow writes "While Solid State Drives are expensive and shouldn't be used exclusively for primary storage, they perform exceedingly well for things like MySQL databases, provided you tweak your kernel, BIOS, and filesystems accordingly. Here's a few tips to get excellent performance out of your new $500-$900 investment on a Linux system."

Comments

Wait, what?

[Briareos]

He recommends disabling journalling and using RAID instead?

So exactly how will a RAID make sure the filesystem metadata is still intact when I yank out the power cable for fun and no profit, as opposed to using a filesystem with a journal?

Sheesh... that's just begging for an accident to happen.

np: Yello - You Gotta Say Yes To Another Excess (Orb Goes The Weasel Mix) (Auntie Aubrey's Excursions Beyond The Call Of Duty (Disc 2))

Re:Wait, what?

[Florian Weimer]

He also recommends to turn on write-back caching. I'm not really sure if this is save. The cache on the SSD is probably not battery-backed.

Re:Wait, what?

[schon]

He also says that the 'noatime' mount option tells the kernel not to read the atime... noatime tells the kernel not to write atimes to the fs.

sweet jebus, is there *anything* technically correct in that article?

Partitioning

[mickwd]

I'm surprised I've heard very little about using Unix/Linux partitioning to get the best out of SSDs.

Seems to me that the best use of an SSD on a normal system is to buy a smallish one (say 16GB) and use it for the read-mainly partitions: say /usr, /opt, maybe /lib.

It would be good to get users' "dot" files in there too. Maybe create a /homedot on the SSD and symlink /home/myname/.example to /homedot/myname/.example.

Even if this doesn't make your applications run much faster, the faster read and seek times are going to make the machine boot faster, load applications faster (especially including the desktop environments, if user directories like .kde and .gnome are on SSD) and compile code faster (with /usr/include, etc on SSD).

Re:Partitioning

[Siffy]

Fragmentation is of little concern with SSDs. The time needed to read out of order bits on a rotating media is much higher as we know, but reading bits out of order in memory or on SSD is almost identical to reading the bit beside it due to the low seek times. Also, partitioning schemes that try to keep the most often accessed files at the beginning of the media lose their edge for the same reason. A SSD has the same performance characteristics from the beginning to the end of the drive from 1% to 99% used capacity. Partitioning could actually shorten the lifespan of the drive, because it could prevent the wear-leveling algorithms from doing their job properly. You'd likely have the most often written to partition fail much sooner than the rest of the drive.

Don't assume things

[jgoemat]

Do the math. Most flash media are good for at least 100,000 writes. They also use wearing algorithms so that each block averages out to about the same. Even if you try to write to a certain block over and over, the algorithms take over and move blocks that are not written very often to those locations, so blocks end up being written to about the same.

With that in mind, let's take the 64 gb model for $899 as an example. Let's say you have a huge workload and are writing at the max of 35MB/sec. At 100,000 writes, 64GB gives you 6.4e15 bytes that can be written before the disk wears out. At 3.5e7 bytes per second, that comes to 1.83e8 seconds. There are 3.16e7 seconds in a year.

That means that at THE MAX write rate and only 100,000 write cycles (not 10 billion), the drive should last at least 5.8 years. Unless you are simply writing to a logging database, you won't be using anywhere near the max write speed and the drive should last decades.