Lifespan
Two common concerns that people have about
SSDs are how long they last, and whether the performance you get when they’re
new will last all the way to old age. These concerns certainly aren’t
unfounded. The transistors in a SSD will last only for approximately 10 years,
or 10,000 writes, whichever comes first – so they have a limited life. What’s
more, in some early models, badly designed firmware meant that performance
could degrade significantly over time.
Two
common concerns that people have about SSDs are how long they last, and whether
the performance you get when they’re new will last all the way to old age
In modern drives, with a modern operating
system and filesystem, the significance of these problems has been reduced
massively thanks to something called TRIM. This helps the drive’s firmware to
manage the allocation of blocks of data, ensuring that each transistor is
written to the minimum number of times without degrading performance.
How big an impact does TRIM have? In one of
the most authoritative articles on the subject, Anand Lal Shimpi found that on
an aged drive, write performance was just 52 percent that of a clean drive
without TRIM; with TRIM, the aged drive performed at 98 percent that of the
clean one. TRIM is worth enabling.
So, how do you get TRIM working? The first
thing to do is make sure that your drive supports it. If it has been bought in
the last few years, it almost certainly will, but anything older and you’ll
need to check whether it’s supported. You can do this with the hdparm command,
as follows: hdparm-I /dev/<ssd>I grep “TRIM supported” Remember to
replace <ssd> with the device name of your SSD. If that commend returns
something, then you’re ready to enable TRIM in the operating system.
To do this, you need to format your
partitions with either the ext4 or btrfs filesystem. These are the only two
that support TRIM. Here at PCF towers, we use ext4, since btrf is still lacking
a stable repair tool, which makes it less able to recover from disaster, and we
recommend that you do the same.
Performance
tweaks
There are one or two tweaks you can apply
that are supposed to increase the speed of your drive, too. One of these
involves aligning your partitions correctly. We don’t go into the finer details
here, but another option is to change the disk scheduler. This dictates which
order blocks are accessed in, and on spinning hard disks the ‘elevator’
scheduler was used to prioritise certain blocks over others (depending on how
close to the centre of a drive a block was, it would take different amounts of
time to access). Since block access is nearly constant on solid state drives,
this can reduce performance, so you might want to consider switching to the
‘noop’ scheduler using the following command” echo nopp >
/sys/block/<ssd>/ queue/scheduler
Modify
the mount
After that, you will need to modify the
mount options of the filesystems, as they don’t enable TRIM support be default.
This can be done by editing the /ect/fstab file. Before making any
modifications to the file, however, make sure you create a backup, as if you
get things wrong in this file, it can stop you from booting.
With
the backup in place, you need to modify, on each line that describes a
partition on your SSD, the part that has the word ‘defaults’ in it.
Cp /etc/fstab /ect/fstab.bk
If anything goes wrong at this point, you
can always boot to a live CD, reverse the copy and then reboot your system to
get it working again.
With the backup in place, you need to
modify, on each line that describes a partition on your SSD, the part that has
the word ‘defaults’ in it. To this, you want to add, discard, so that the
entire line looks something like this: /dev/sda1 / ext4 defaults, discard 01
That’s it. Now you just need to save the
file, reboot, and your drive has TRIM support enabled. This is the most
important tweak to apply to your SSD.
SSD Performance
Intel 330 (Sandforce)
·
Postmark (transactions per second): 790
·
Compile Bench Initial Create (MB/s): 300
·
Compile Bench Compile: (MB/s): 480
·
Compile Bench Read Compiled Tree (MB/s): 580
·
Unpacking the Linux Kernel (seconds): 90
Crucial M4 (Marvell)
·
Postmark (transactions per second): 790
·
Compile Bench Initial Create (MB/s): 120
·
Compile Bench Compile: (MB/s): 210
·
Compile Bench Read Compiled Tree (MB/s): 390
·
Unpacking the Linux Kernel (seconds): 90
Extending
life
There are other ways to tweak your drive
and extend its life still further.
The easiest of these other techniques is to
add the noatime option to your mount options, just like we did with discard
above. Normally, Linux filesystems store the last time a file was read from,
and the last time it was modified. With the noatime option, it will store only
the last time it was modified, reducing the number of writes in order to keep
this metadata up to date and increasing the life of your drive.
You
can also increase the life of your drive by thinking carefully about what
partitions you put on it.
A word of warning, however: older
applications, such as Mutt, won’t function properly if you enable noatime, so
first check application compatibility.
You can also increase the life of your
drive by thinking carefully about what partitions you put on it. For instance,
if you have a traditional hard drive available on your system as well, you
might consider using the SSD for filesystem that don’t change frequently, such
as / and /home, while putting things such as /var,/tmp and swap on the spinning
disk.
If this isn’t an option, you can make other
changes to reduce the frequency of writes to these directories. For instance,
you can increase the severity of log messages which will be recorded by editing
the / ect/rsyslog.conf file (see man rsyslog.conf for details), or you can
decrease your system’s ‘swappiness’, which encourages it to use swap space less
frewuently. You can do this be executing: echo 1> /proc/sys/vm/swappiness
The underlying storage technology in most
SSDs varies little. What makes the biggest difference to their performance is
the controller and firmware the hardware that decides how and where to write
your data on the drive. A bad controller can slow your drive down, particularly
as it ages, and can lead to varying performance across different-sized writes
(like 4k vs 9k).
The two test drives that we have represent
two competing controller solutions. The Crucial M4 uses a Marvell controller,
while our Intel 330 uses a Sandforce one. These same controllers are used on
many different drives, so our results will be able to inform your buying
decisions, even if you don’t choose either of the specific drives we have on
test. We tested the drives using the Postmark, Compile Bench and Kernel
Unpacking tests in the Phoronix Test Suite, with a view to seeing how the
drives performed in real situations. All of the tests were carried out on an
Ubuntu 12.04 system, with ext4 and the discard option set in / ec/fstab.
The Compile Bench test is perhaps the most
interesting, as its operations attempt to simulate operations that age a
filesystem – the most likely scenario to tax the controller. On these tests,
the Intel drive, with a Sandforce controller, performed much better. That said,
the Crucial drive was much quicker when it came to dealing with many small
files in the PostMark test, and marginally better when unpacking the kernel.
Both drives are in the same price bracket,
being available online anywhere from $126 and upwards.
