I have been using an Intel 520 SSD on my Debian unstable for > 3 years and I have not done any such setting let alone knowing they exist. Should I pay heed or should I continue using my SSD like this? Thoughts?
I'd recommend to follow up at least on the post-installation tips, to reduce swappiness and writes on the SSD drive. That way you can keep your SSD working longer.
I wouldn't bother with any of this. The effects on the SSD are too low to be worth it and there is no discussion on the tradeoffs that are being taken. Disabling hibernation is really a shame for one. Trim is done excessively and the benefit is not that big. The weekly trim should suffice and no need to do it on boot.
I also doubt the disk scheduler is of any importance, as long as there are enough IOs in the queue in the disk it will be fast, otherwise it will not. All schedulers will allow multiple IOs in the queue for all I know.
I do the noatime for any system without regard if it is an SSD or HDD. I just don't use atime at all to bother about the extra work needed to maintain it.
I stopped reading at that point - why buy an SSD if you're going to force everything to download over an internet connection to preserve it? Just use an HDD with caching, it'll be faster.
It's terrible advice, especially considering the point of the page is about optimising your computer. "Now let's turn off something that speeds up your web browsing..." - yeah, thanks!
This pretty much all seems to be a lot of fiddly work that tries to reduce writes to your SSD.
People Who Know in the industry know that any non-bottom-of-the-barrel SSD bought in the last -like- five years or so will endure many tens of TBs of writes.
If we look at Tech Report's SSD Torture Test [0], we know with some confidence that consumer-level SSDs will endure hundreds of TBs of writes before failing.
To provide some perspective for those numbers: My Linux laptop has encrypted swap, btrfs root partiton, and encrypted btrfs /home all on the SSD, and sees frequent compiles-from-source (I run Gentoo Linux.). Other than mounting my filesystems with the "discard" option, I've performed no SSD-specific configuration step or fiddled with any VM tunables.
Under this workload and configuration, I have written 20.4TB and read 66.8TB over 3.9 years. SMART indicates that zero blocks have been reallocated and that the drive is in perfect health.
In short, if you've a consumer or developer's workload, don't worry about SSD media longevity. Regardless of who you are, strongly consider benchmarking any configuration tweaks that folks claim will improve performance.
> This pretty much all seems to be a lot of fiddly work that tries to reduce writes to your SSD.
The page may look like there are many steps involved, but actually many do not apply to recent distributions. It's more or less a 4-5 steps for a recent distro. hardly what I would call "a lot of fiddly work".
You latched on to the least important part of my comment.
The thing is, the linked article is a grab bag of outdated (mount filesystems with noatime [0]) or just plain wrong (btrfs is bad for SSDs) factoids and bits of advice. It's clear that the author hasn't gone to the trouble to fact or efficacy check most of his assertions. We need fewer top-ten lists of cargo-cult suggestions to extend the life of your PC, not more. :)
What's more, you're going to pains -however small- to extend the life of something that will easily last for far more than five years. Five years is a long time in the SSD market. My ~five year old 100GB SSD is still going strong. It cost ~$400 when I purchased it. Today I can spend ~$400 and get a 1TB drive that's substantially faster than and at least as reliable as this one.
There's something to be said for frugality. I know: I've been using the same laptop for the past eight years. There's also something to be said about not worrying about wear when using highly durable tools that are designed to last for a decade or more. [1]
[0] relatime has been available since ~2007 and was made a part of the defaults mount option since ~2009.
[1] After all, if a tool lasts for ten years, you'll only ever buy ten of them in your lifetime.
Supporting anecdata: I had a windows 7 gaming machine that saw a fair amount of use each day, with the pagefile on an SSD, and no tuning. Took about four years before the drive started failing (well, failing noticeably as a user).
> Took about four years before the drive started failing (well, failing noticeably as a user).
Was the SSD made by OCZ or had a Sandforce controller by any chance?
Also anecdotal, but my 160GB Intel X25-M 'G2' has been working perfectly for the past 5 years and 10 months. So far I have written 16.92 TBs to it [1] and until I moved the drive into another PC I had been running games and VMs from it.
FWIW, the drive from which I quote usage stats in my comment is a 100GB OCZ Vertex LE. So, this is the fabled "double whammy" of OCZ-manufactured drive and early SandForce chip.
What about SSHD drives - does Ubuntu have special drivers for them? Can I get my code files to be on the SSD part of the SSHD drive or will they just be allocated to the slow HDD part?
These devices do not expose their inner SSD and only utilize it as a cache.
You are probably better off with an SSD standalone or with a full blown SSD as a block cache to the HDD in part and as a direct drive in the other part.
There's also profile-sync-daemon [0] that moves browser profiles into a ramdisk to save writing to/from the SSD all the time.
I think a copy-on-write filesystem like btrfs would be better on SSDs because they do not change written data but rather write to a new area on the drive, requiring less erases on the SSD's side.
There's also F2FS (Flash-Friendly File System) which has been in the Linux kernel for a while now that specifically targets flash based drives.
Though I agree that most of these optimizations do not seem necessary on modern SSDs.
I would argue that preferring to reuse the same space of the SSD instead of using new space as you propose (cow, et al.) is the better approach. This way you don't need to use trim that much and the SSD will anyway write it into a different place.
It should be noted that while an SSD can't write before erasing it will actually not even attempt that. The SSD maintains a mapping from LBA to physical flash chip and offset and will write to a completely different place. It will then mark the old location as unused and erase it when it can spare some time and power.
I'm pretty sure that the SSD performs wear leveling regardless of whether you're overwriting an existing file or creating a new copy. Just because you're logically rewriting the contents of a file doesn't mean the SSD will store the new contents in the same physical location.
F2FS is for direct NAND access, if you do it over an SSD that already has an FTL (flash translation layer) you'll gain nothing and only cost extra writes.
This is bad advice imo. A SSD offers small capacity for a big price. It is a bad match for preserving data.
Its advantage is its speed, especially in seek times, but also on read/write operations.
If one wants to “get his money back” the best way is to utilize the SSD to its fullest instead of trying to preserve it for ten years. Write on it as much as you can. Use it to make your system faster. Use it to hide your setup's shortcomings.
Couple years back, I had only 8GB of RAM on my system. The first thing I did when I got a SSD was to put the swap on it. The zero-seek times (compared to HDDs) made the dreaded swap operations almost imperceptible. What worths more? The SSD or the ability to do my work without hinders?
Other bad advice in the article:
- Use noatime: this is old, use relatime.
- Do not use btrfs: compression, deduplication, COW, snapshots etc are very useful for the small sized SSDs
- Do not enable hibernation: Maybe we should return to windows '98
- Disable browser cache: facepalm, just try browsing like this...
Ommited advice from the article:
- Use part of the SSD as a cache for your HDDs (native support by LVM)
In short: do not try to protect your SSD. Try to kill it as fast as possible. :)
It's fine as long as people know what they are doing is ridiculous. I have a friend who both tries to hyper mile and as well as prevent any wear on his brakes on his Diesel VW Golf TDI. As in, his objective is to never, ever touch his brakes, or accelerate (significantly). He plans out his highway on-ramps to avoid sudden acceleration, rarely passes, and gauges stop-lights blocks in advance to reduce braking.
Is this needed in a modern car, or does it make driving said care more pleasurable, (or, for that matter, safe?) No, in call cases. But, he takes a particular pleasure about taking his vehicle into the dealer (free, once a year), and at 75,000 miles being told that his brakes look like they've got 10,000 miles on them.
So, if you read the advice on SSDs in this (ridiculous to some) vein, then It's a fun read.
The practice of hypermiling is about burning less fuel to reach your destination. Likewise, avoiding unnecessary braking saves on replacement costs. It's certainly not needed for any car, but it saves money.
Your friend's practice seems a bit excessive to me, though I can understand one adopting some good driving habits to reduce wear and increase mileage. It usually leads to more safe roads too, due to less aggressive driving behaviour.
A thing I can't understand are screen protectors used by people with an office job. The amount of R&D put into modern phones' screens and oleophobic coating is huge. Your phone's screen is designed to withstand both hits and dirt, to let your fingers slide with minimal friction and to allow you perceive every last pixel of your QHD panel (which has its own huge amount of R&D). Why would you miss all these by gluing a $5 piece of plastic on top of it?
I agree! Many of the SSD "tweaks" mentioned are unnecessary and seem to originate from the early days of consumer SSDs (2007-early 2009). For some bizarre reason they still perpetuate and I am not sure why.
Disabling the browser cache is a good example. Back then we had many drives based on JMicron's infamous JMF602 controller such as the G.Skill Titan and Apex, Core v2 & Solid from OCZ. Once thing these all had in common were incredibly poor random 4KB write latencies of between 0.5-2 seconds [1][2] which understandably lead to frequent pauses or stuttering in the operating system. The general advice in these cases was to move the browser cache to a HDD or RAM disk in addition to disabling or moving the pagefile. I am not sure why but many people seemed happy with this solution. If I had purchased an SSD that exhibited this problem I would have returned it to the place of purchase for a full refund since they clearly weren't fit for purpose and shouldn't have been sold in the first place!
Item 17 isn't true [3]. Windows 7 onwards will detect solid state drives and will make the necessary adjustments itself (including disabling defrag just for the SSD). What many of these guides fail to mention is that if you completely disable defrag you are also disabling the automatic defragmentation of any HDDs that are connected to the same computer. Also, in Windows 8.x/10 the defrag tool now deals with storage optimization and does a lot more than defragging such as sending TRIM hints to SSDs [2][3] so you definitely don't want to disable that.
If you have cloned a Windows install from a HDD to an SSD you can force Windows to detect the drive as an SSD by running the following from an elevated Command Prompt (although WinSAT will run without any user input eventually):
winsat formal -restart clean
One reason for disabling hibernation was because SSDs were small (< 64GB) and the hiberfil.sys in Windows would take up a non-trivial amount of disk space if you had a PC with 4GB-8GB RAM. These days it's a non-issue since capacities are larger and the as The Tech Report have proven, it takes a lot of effort to wear out an SSD. Also, if you are using Windows 8.0 onwards disabling hibernation will also disable the fast startup feature.
Another very recent myth is that SSDs will lose data in as little as 7 days if left in a powered-off state [5]. Thankfully this has been thoroughly debunked [6].
Ah, typical Linux article with an obligatory insult for Windows. Hope OP realizes Windows disables defrag for SSDs, and basically does everything described in the article without needing user intervention.
Next, you don't have to over-provision unpartitioned space AND preserve 20% of partitioned free space. It's one or another, the point is to have enough free space for proper wear leveling.
Hibernation can stay enabled, it just dumps RAM contents into a file, once. SSDs are much more vulnerable to small frequent writes (log files, browser cache, etc) due to write amplification and minimum write size (http://www.ni.com/product-documentation/10126/en/).
I don't know about earlier Windows, but Windows 8 does not attempt to defragment drives that identify themselves as being solid-state. It does invoke TRIM on drives that advertise that feature, and confusingly, this is done through the same defragmentation UI.
Why 'confusingly'? It's only natural to keep drive maintenance in one place. You don't ever need to invoke defrag/trim manually as they are scheduled to run whenever PC is not in use.
It's confusing to people who are told to disable defragmentation on SSDs. It's the same button for both HDDs and SSDs, and both TRIM and defragmentation are referred to using the same word, 'optimization'[0]. An unaware user would not know the difference.
18. Now you'll be able to enjoy your SSD carefree!
This should have been step 1. SSDs have a massive lifetime these days, you don't need to do any of the other steps, some of them will even slow down your computer.
It can work out nicely if most of what you do is the size of the SSD and the total capacity is higher than the SSD capacity (i.e. lots of rarely used stuff).
In fact, I worked on an enterprise storage that did just that and it significantly improved performance for many workloads. There are open-source solutions for that in Linux that integrate into LVM and do that pretty much without any other interaction by the user. bcache comes to mind but there were a few others as well.
50 comments
[ 4.1 ms ] story [ 129 ms ] threadI also doubt the disk scheduler is of any importance, as long as there are enough IOs in the queue in the disk it will be fast, otherwise it will not. All schedulers will allow multiple IOs in the queue for all I know.
I do the noatime for any system without regard if it is an SSD or HDD. I just don't use atime at all to bother about the extra work needed to maintain it.
Are you taking backups?
So long as you're taking backups you probably should worry about this kind of excessive noodling.
People Who Know in the industry know that any non-bottom-of-the-barrel SSD bought in the last -like- five years or so will endure many tens of TBs of writes.
If we look at Tech Report's SSD Torture Test [0], we know with some confidence that consumer-level SSDs will endure hundreds of TBs of writes before failing.
To provide some perspective for those numbers: My Linux laptop has encrypted swap, btrfs root partiton, and encrypted btrfs /home all on the SSD, and sees frequent compiles-from-source (I run Gentoo Linux.). Other than mounting my filesystems with the "discard" option, I've performed no SSD-specific configuration step or fiddled with any VM tunables.
Under this workload and configuration, I have written 20.4TB and read 66.8TB over 3.9 years. SMART indicates that zero blocks have been reallocated and that the drive is in perfect health.
In short, if you've a consumer or developer's workload, don't worry about SSD media longevity. Regardless of who you are, strongly consider benchmarking any configuration tweaks that folks claim will improve performance.
[0] http://techreport.com/review/27909/the-ssd-endurance-experim... (But make sure to also check out the intro article: http://techreport.com/review/24841/introducing-the-ssd-endur... )
The page may look like there are many steps involved, but actually many do not apply to recent distributions. It's more or less a 4-5 steps for a recent distro. hardly what I would call "a lot of fiddly work".
The thing is, the linked article is a grab bag of outdated (mount filesystems with noatime [0]) or just plain wrong (btrfs is bad for SSDs) factoids and bits of advice. It's clear that the author hasn't gone to the trouble to fact or efficacy check most of his assertions. We need fewer top-ten lists of cargo-cult suggestions to extend the life of your PC, not more. :)
What's more, you're going to pains -however small- to extend the life of something that will easily last for far more than five years. Five years is a long time in the SSD market. My ~five year old 100GB SSD is still going strong. It cost ~$400 when I purchased it. Today I can spend ~$400 and get a 1TB drive that's substantially faster than and at least as reliable as this one.
There's something to be said for frugality. I know: I've been using the same laptop for the past eight years. There's also something to be said about not worrying about wear when using highly durable tools that are designed to last for a decade or more. [1]
[0] relatime has been available since ~2007 and was made a part of the defaults mount option since ~2009.
[1] After all, if a tool lasts for ten years, you'll only ever buy ten of them in your lifetime.
Was the SSD made by OCZ or had a Sandforce controller by any chance?
Also anecdotal, but my 160GB Intel X25-M 'G2' has been working perfectly for the past 5 years and 10 months. So far I have written 16.92 TBs to it [1] and until I moved the drive into another PC I had been running games and VMs from it.
[1] http://i.imgur.com/u3AfP9R.png
You are probably better off with an SSD standalone or with a full blown SSD as a block cache to the HDD in part and as a direct drive in the other part.
http://forum.crucial.com/t5/Crucial-SSDs/Solution-Crucial-V4...
I think a copy-on-write filesystem like btrfs would be better on SSDs because they do not change written data but rather write to a new area on the drive, requiring less erases on the SSD's side.
There's also F2FS (Flash-Friendly File System) which has been in the Linux kernel for a while now that specifically targets flash based drives.
Though I agree that most of these optimizations do not seem necessary on modern SSDs.
[0] https://github.com/graysky2/profile-sync-daemon
It should be noted that while an SSD can't write before erasing it will actually not even attempt that. The SSD maintains a mapping from LBA to physical flash chip and offset and will write to a completely different place. It will then mark the old location as unused and erase it when it can spare some time and power.
https://lwn.net/Articles/518988/
If one wants to “get his money back” the best way is to utilize the SSD to its fullest instead of trying to preserve it for ten years. Write on it as much as you can. Use it to make your system faster. Use it to hide your setup's shortcomings.
Couple years back, I had only 8GB of RAM on my system. The first thing I did when I got a SSD was to put the swap on it. The zero-seek times (compared to HDDs) made the dreaded swap operations almost imperceptible. What worths more? The SSD or the ability to do my work without hinders?
Other bad advice in the article:
Ommited advice from the article: In short: do not try to protect your SSD. Try to kill it as fast as possible. :)Is this needed in a modern car, or does it make driving said care more pleasurable, (or, for that matter, safe?) No, in call cases. But, he takes a particular pleasure about taking his vehicle into the dealer (free, once a year), and at 75,000 miles being told that his brakes look like they've got 10,000 miles on them.
So, if you read the advice on SSDs in this (ridiculous to some) vein, then It's a fun read.
A thing I can't understand are screen protectors used by people with an office job. The amount of R&D put into modern phones' screens and oleophobic coating is huge. Your phone's screen is designed to withstand both hits and dirt, to let your fingers slide with minimal friction and to allow you perceive every last pixel of your QHD panel (which has its own huge amount of R&D). Why would you miss all these by gluing a $5 piece of plastic on top of it?
Some of us prefer matte, non-mirror screens.
Disabling the browser cache is a good example. Back then we had many drives based on JMicron's infamous JMF602 controller such as the G.Skill Titan and Apex, Core v2 & Solid from OCZ. Once thing these all had in common were incredibly poor random 4KB write latencies of between 0.5-2 seconds [1][2] which understandably lead to frequent pauses or stuttering in the operating system. The general advice in these cases was to move the browser cache to a HDD or RAM disk in addition to disabling or moving the pagefile. I am not sure why but many people seemed happy with this solution. If I had purchased an SSD that exhibited this problem I would have returned it to the place of purchase for a full refund since they clearly weren't fit for purpose and shouldn't have been sold in the first place!
Item 17 isn't true [3]. Windows 7 onwards will detect solid state drives and will make the necessary adjustments itself (including disabling defrag just for the SSD). What many of these guides fail to mention is that if you completely disable defrag you are also disabling the automatic defragmentation of any HDDs that are connected to the same computer. Also, in Windows 8.x/10 the defrag tool now deals with storage optimization and does a lot more than defragging such as sending TRIM hints to SSDs [2][3] so you definitely don't want to disable that.
If you have cloned a Windows install from a HDD to an SSD you can force Windows to detect the drive as an SSD by running the following from an elevated Command Prompt (although WinSAT will run without any user input eventually):
One reason for disabling hibernation was because SSDs were small (< 64GB) and the hiberfil.sys in Windows would take up a non-trivial amount of disk space if you had a PC with 4GB-8GB RAM. These days it's a non-issue since capacities are larger and the as The Tech Report have proven, it takes a lot of effort to wear out an SSD. Also, if you are using Windows 8.0 onwards disabling hibernation will also disable the fast startup feature.Another very recent myth is that SSDs will lose data in as little as 7 days if left in a powered-off state [5]. Thankfully this has been thoroughly debunked [6].
[1] http://www.anandtech.com/show/2738/17
[2] http://www.anandtech.com/show/2614/7
[3] http://www.hanselman.com/blog/TheRealAndCompleteStoryDoesWin...
[4] http://www.ghacks.net/2012/08/19/why-weekly-defrags-are-turn...
[5] http://www.extremetech.com/computing/205382-ssds-can-lose-da...
[6] http://anandtech.com/show/9248/the-truth-about-ssd-data-rete...
Next, you don't have to over-provision unpartitioned space AND preserve 20% of partitioned free space. It's one or another, the point is to have enough free space for proper wear leveling.
Hibernation can stay enabled, it just dumps RAM contents into a file, once. SSDs are much more vulnerable to small frequent writes (log files, browser cache, etc) due to write amplification and minimum write size (http://www.ni.com/product-documentation/10126/en/).
[0] http://www.oszone.net/user_img/vadblog/ssd-defrag-bug-en01_m...
18. Now you'll be able to enjoy your SSD carefree!
This should have been step 1. SSDs have a massive lifetime these days, you don't need to do any of the other steps, some of them will even slow down your computer.
The 850 Pro I've got in my machine has a stated write lifetime of 150TB.
And chances are, it'll do a lot more than that, it's just the number they'll look at for the 10 year warranty.
Personally I just fully wipe a new ssd and put discard in fstab.
In fact, I worked on an enterprise storage that did just that and it significantly improved performance for many workloads. There are open-source solutions for that in Linux that integrate into LVM and do that pretty much without any other interaction by the user. bcache comes to mind but there were a few others as well.
With ~250GB SSDs going for like 100 bucks it's like a no-brainer to add one to a desktop.