I often read that one should not place swap partitions on a SSD drive, as this may harm the device. Is this true? Can you please explain the reason to me?

Because I otherwise would have thought that placing swap on an SSD is the best choice, as it's much faster than HDDs and therefore swapping RAM contents to the SSD is not as slow as it would be with the HDD...

up vote 58 down vote accepted

Still today Flash RAM cells built in SSDs have a limited lifespan. Every write (not read) cycle or better every erasure wears a memory cell and at some time it will stop working.

The amount of erase cycles a cell can survive is highly variable, and flash from modern SSDs will do much better than some years ago. In addition the intelligent firmware will take care of evenly distributed erasures between all the cells. In most drives unused areas will also be available to backup damaged cells and to delay aging.

To have a value we can use to compare the endurance of an SSD JEDEC published standards to measure the life span of an SSD. A widely available value for endurance is TBW (TeraBytes Written, some also say total bytes written) which says how many bytes we can write before failure of the drive. Modern SSDs can be as low as 20TB for a consumer product but can reach more that 20.000 TB in an enterprise-level SSD.

Having said that, both, the lifespan, and the use of an SSD for swap depends...

System with plenty of RAM

On a system with plenty of RAM and not so many memory consuming applications we will almost never use swap. It is merely a safety measure to prevent data loss in case an application ate up all our RAM. In this case wearing of an SSD from swap will not be an issue. But then having this mostly unused swap on a conventional hard drive will not lead to any performance drop so we can safely put our swap on that so much cheaper hard drive and use the gained space on our SSD for something more useful.

System with too little RAM

Things are different on a system where RAM is preciously rare and can not be upgraded. Then swapping may indeed occur more often, especially in cases we run memory intensive applications. In these systems a swap on SSD may lead to a dramatic improvement of performance. But this is at cost of a somewhat shorter lifespan of the SSD. This may however still not be that short to be worried. It may more liekly that by the time we find our SSD is dying we already had long thought of replacing it because 10 times the storage will cost only a fraction of what it does today.

We need to hibernate

Well, waking from hibernation is indeed very fast from a SSD. If we are lucky and our system survives a hibernation without issues we may consider to use an SSD for that. It will wear the SSD more than just booting from it, but we may fell it is worth it.

But admittedly booting from an SSD may not take much longer, and it will wear the SSD far less. I do not hiberante, I suspend to RAM. or I enjoy the very fast booting from SSD.

The SSD is the only drive we have

In this case we do not really have a choice. We do not want to run without swap so we must put it on the SSD. We may however want to choose a smaller swap partition in case we do not plan to hibernate.

Note on speed

SSDs are best in quickly accessing and reading many small files and data transfer from sequentially reading small or medium sized files are better than conventional hard drives. For writing and to a lesser extent reading large audio or video streams or other long not fragmented files a conventional fast hard drive may still perform better. Older SSDs may lose performance over time or after they are fairly full.

  • 1
    So we can conclude that we should use SSDs preferably to store data that ideally are written once (ore rarely) and need to be read pretty often. Like the system files, program files or the home folder's data directories (Music, Videos, ...). Is there a rough number on how many write/erase cycles a modern average SSD cell should survive? 1000? 10000? And yes, I understood that the controller tries to distribute usage evenly among all cells to enlarge the life span. – Byte Commander Jul 25 '15 at 8:50
  • @ByteCommander See edit for some more points regarding your comment. – Takkat Jul 25 '15 at 9:21
  • I think the note on speed is misleading - SSD's will outperform hard drives - the fastest (SAS, 15000 rpm) drives provide a seqential access speed of about 250MB/sec while an SSD provides almost double that (and a regular hard drive pales in comparison at about 110MB/sec - SSD's will outperform hard drives in sequential reads, the question is one of cost. – davidgo Nov 18 '16 at 19:34
  • @davidgo it is true that In general an SSD will perform much better than a hard drive, especially if the SSD was new. There are however reports on quite significant performance drops not only from an ageing SSD but also from sequential reading over a longer time span (such as video streaming). See e.g. this post on SU and in depth explanation from seagate. So we should not rely on the initial great values to last forever. – Takkat Nov 18 '16 at 22:04
  • 1
    Interesting post from Seagate, however this was written circa 2010 - and SSD's came a long way between then and 2015 - particularly with respect of background garbage collection and wear leveling - which drastically alter the landscape - see techreport.com/review/27909/… from as way back as 2013. Also, back in 2010, ssd controller cards were a lot buggier. – davidgo Nov 18 '16 at 23:08

Early SSDs had a reputation for failing after fewer writes than HDDs. If the swap was used often, then the SSD may fail sooner. This might be why you heard it could be bad to use an SSD for swap.

Modern SSDs don't have this issue, and they should not fail any faster than a comparable HDD. Placing swap on an SSD will result in better performance than placing it on an HDD due to its faster speeds.

Additionally, if your system has enough RAM (likely, if the system is high-end enough to have an SSD), the swap may be used only rarely anyway.

  • 2
    I am tempted to believe this, but I want to wait for further reactions and would also appreciate any references as proof. I will accept an answer when there is valid proof or a clear majority for one point. – Byte Commander Jul 24 '15 at 19:59
  • 1
    While not statistically valid for life of your SSD. SSD life test 2015 final techreport.com/review/27909/… Shows life is very long even for the ones that failed first. I have had hard drives fail within a year, but that is not normal. My 4GB of RAM system almost never used swap anyway. – oldfred Jul 24 '15 at 20:48
  • My question here is: If I have an SSD AND a good amount of ram, should I try to constain my application(s) within the RAM like in the old HDD days, or can I let it run wild with SSD. Seems like it's still worth it but maybe not. – jerclarke Mar 10 '16 at 17:24

HDD technology uses a magnetic process for data manipulation and storage. This process is noninvasive, meaning you can pretty much manipulate data on a disk drive infinitely. That is until the mechanics start to fail. In contrast SSD technology does not run the risk of mechanical failure. But what is a concern is how it stores its data. For data storage SSDs use controlled bursts of electrical energy. The semiconductors that are hit with this electric current slowly wear out from the process as they are used over time.

This process has been improved upon through software and hardware updates. Early adapters found that OS's were not programmed to properly store data the way an SSD does. This adversely put the SSD through large amounts of read/write cycles. Also most older BIOSs do not properly recognize an SSD and this caused issues as well.

The introduction of UEFI and OS's updates corrected most of the issues that early SSD owners had. Also, as with any production process, SSDs themselves have gotten better at managing and maintaining the degradation of NAND flash drives.

However, it is still a concern that your SSD has a limited amount of read/write cycles before it can no longer store data. Although, that concern is just as marginal as your HDD failing.

There's a very in-depth podcast about the subject here if you'd like to read up on the topic further.

Even if you have enough RAM, you might still want to prevent any file copy or search to swap out the applications from RAM. This might be the case on file servers (NAS, SAMBA, FTP) which might be involved in large file operations.

In order to do that it's best to set in /etc/sysctl.conf: vm.swappiness=1 vm.vfs_cache_pressure=50

The first setting prevents disk cache (e.g. doing cp) to swap out existing apps from RAM. The normal default setting on that is 60. Note that using 0, although more aggressive, has been sometimes reported to generate out-of-memory errors.

The second setting prevents file searches (e.g. doing find) to swap out existing apps from RAM. The normal default setting for that is 100.

Although the author mentioned in reference does not refer explicitly to SSD's, this approach also reduces wear on SSD due to reduced swapping and he also provides example how to test it.

Reference: https://rudd-o.com/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that

Life Vs Performance Balance.

You bought an SSD for its performance advantages and not simply for increasing battery life right? So use your SSD for that very purpose, to make your system quicker.

If you can afford to add more RAM to reduce *swap I/O then this will clearly increase the life span of your SSD as another performance drain is obviously I/O cycles to swap space on a filesystem.

Again like so many aspects of your system configuration it’s often not down to one single rule adoption that fits all. User needs differ and as such system requirements and thus configuration must differ in order to meet these needs, put simply it boils down to how you configure your system.

If you have the space to hold an SSD in addition to your none SSD drive, then write files that will rarely change to your none SSD drive and keep often accessed files on your SSD drive.
This will ensure that …

[1] - The *trim features will have the resources to perform the necessary steps to evenly use all of the drive. [Benefit = Life]

[2] - Your I/O latency will be reduced with the high speed SSD device being used to access an often accessed filesystem. [Benefit = Performance]

Configure your temp filesystem to utilise space when required for your particular system needs, if you have enough RAM then consider setting your swappiness level to be less aggressive, this will ensure that…

[1] - SSD I/O is reduced yet your system will still meet the demands of its user(s). [Benefit = Life]

Do you really need all off those logs? Consider what your system is logging and where.

[1] – SSD I/O is reduced as log file access is reduced. [Benefit = Life & Performance]

There are a heap of other aspects to your system configuration that can make a none SSD system perform faster, default system builds have a tough metric to fulfil, pure performance or keeping data safe and secure or a balanced mixture of them all. If you apply the same mentality to what you write and to which device, you can drastically increase both performance and at the same time increase the life span of your SSD.

*swap - Remember this isn't just used when resources are low, the swappiness configurable for many Linux distro's out of the box by default will park long running processes of low priority further down the performance ladder into swap space)

*Trim – worth verifying you have it enabled, a good article on what trim is and how it works: http://searchstorage.techtarget.com/definition/TRIM

I think it's because SSD drives are like flash memory, where they wear out the more you have read and write cycles. Swap would make that so much worse, since swap is constantly writing to the swap file.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.