How to increase the life of SSD

The filesystems of earlier days were designed around hard disks that were mechanical in nature. However in case of SSDs the excessive writes or reads decrease its life. Modern distributions have tuned the filesystem or the kernel so that in case of SSD the wear and tear is minimal. Can anyone suggest a tool or Howto that can do this for EOS.

Perhaps the following article will function as a start point for your inquiry:

Also putting Firefox’ profiles on RAM (if you use Firefox of course) will also help reducing disk I/O operations:

Another thing to consider is using ZRAM as swap device to reduce disk read-write cycles:


Take advantage of BTRFS compression. (Simple Analysis of btrfs zstd compression level)


the learning curve of installing EOS alongwith another OS was huge. importantly was not sure whether the install would go well as planned. it did go well as planned but i installed EOS on an ext4 partition probably.
So i dont think i have a btrfs choice now.

thanks. mine is a kingston ssd … but

yay -Syu kingston_fw_updater         {long_cmd_duration}
[sudo] password for pannet1: 
:: Synchronizing package databases...
 core                  137.5 KiB   197 KiB/s 00:01 [-----] 100%
 extra is up to date
 community               5.9 MiB  3.67 MiB/s 00:02 [-----] 100%
 multilib is up to date
 endeavouros is up to date
:: Starting full system upgrade...
 there is nothing to do
:: Searching databases for updates...
:: Searching AUR for updates...
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur:1]  kingston_fw_updater-205-010

  1 kingston_fw_updater              (Build Files Exist)
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
:: PKGBUILD up to date, Skipping (1/0): kingston_fw_updater
  1 kingston_fw_updater              (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
:: (1/1) Parsing SRCINFO: kingston_fw_updater
==> Making package: kingston_fw_updater 205-010 (Saturday 25 December 2021 01:51:21 AM)
==> Retrieving sources...
  -> Found
==> Validating source files with md5sums... ... FAILED
==> ERROR: One or more files did not pass the validity check!
 -> error downloading sources: kingston_fw_updater 
	context: exit status 1 

==> Making package: kingston_fw_updater 205-010 (Saturday 25 December 2021 01:51:24 AM)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found
==> Validating source files with md5sums... ... FAILED
==> ERROR: One or more files did not pass the validity check!
 -> error making: kingston_fw_updater

Looks like the PKGBUILD doesn’t have a correct checksum.

You could update the checksum manually following the instructions below:

In some directory under your /home:

  1. yay -G kingston_fw_updater
  2. cd kingston_fw_updater
  3. updpkgsums
  4. makepkg -si


1 Like

For the bird brain i have, this is a project wil take atleast 1 or 2 days of dedicated work. i am not mentioning about the kingston_fw_updater, the overall SSD wear and tear thingy.
Will keep posted on the developments here. Thank you very much for the guidance.

How to increase the life of SSD

Definitely don’t use Kingston SSD / RAM, that’s 1st rule.


Yeah, in my household we do not use Kingston SSDs and Seagate HDDs.


This is even worse for the SSD!

BTRFS isnt in any kind good for the lifespan of a ssd.

If you want to have the maximum lifespan for your ssd, you should consider to buy much more ram (32gb and more would be good) and f2fs as filesystem.

But, to be realistic, simply stop care about lifespan (if you didnt run the ssds on servers).

Why? It simply because of how realistic you could write the entirely Space on a ssd.

Quick search on the internet says for example, that for a 40$ cheap ssd (240gb) from corsair says, that it could write 80TB(!!) data, until it shows wear.

So, if you write EVERY DAY 20GB Data on the SSD, you have a lifespan of 11 Years, until it shows official wear. And after that, it would probarly last other 11 Years. But the normal user, writes only few MB of data every day in a year. Including Browsing and Updating.

For me, i have for example a SSD from Intel from 2009. 60GB Big. And it runs until today as disk for Proxmox on my Server… Without any Problem.

Just because im Curios. Why? Kingston makes very good ram. special for server (but arent cheap tho’).


At least THAT I can confirm, unfortunately …

This article has some useful tips;

1 Like

Could you shed some light on why it is not?

If its compression reduces the write volume by about 40% I would think it would be good for ssd. And that’s the perception of Fedora.

I’m not quite normal then. :slight_smile:

If your definition of very good is extremely unreliable & die fast in a spectacular fashion - then yeah, it’s stellar. :rofl:

It’s super cheap garbage, most of the times not even capable of it’s own specs, and even sometimes having physically different chips on same board (yes, legit ones, both cheap and pricey), doesn’t matter how much RGB lights you put on top of it so customers would get impression it’s something legit and no-nonsense quality unlike any no-name brand.

Even with no-name brands you probably would have better 50/50 chance of luck, than with Kingston.

Can’t comment on that, with lack of experience, but i certainly would never trust this crap with both my money and my server, because there is nothing that indicates it as good idea.

1 Like

Interesting wiki page. I tried to install firefox-sync linked in the wiki page. However I don’t understand what the installer does.

Where does the source come from in this pkgbuild (there’s only an external reference to the wiki page in the pkgbuild)? Shouldn’t there be a git repo somewhere in the build file?

# Maintainer: Que Quotion <>
# Contributor: Ramana Kumar <>
pkgdesc="Speed up Firefox using tmpfs"
arch=('i686' 'x86_64')
depends=('rsync' 'firefox')
source=(${pkgname} "${pkgname}.service")
package() {
  sed -i "3 c\
LINK=$(ls -d1 ~/.mozilla/firefox/*.default | head -n 1 | xargs basename)
" $pkgname
  install -Dm 755 ${pkgname} ${pkgdir}/usr/bin/${pkgname}
  install -Dm 644 {"${srcdir}","${pkgdir}"/usr/lib/systemd/user}/"${pkgname}".service
1 Like

Kingston SSDs are gaining somewhat of a reputation for unexpectedly and suddenly stopping to work, with complete data loss, of course.

Now, if your RAM suddenly stops to work, you go to the shop and get new RAM. Sure, it sucks, but it’s an easy fix and, in the long run, not a big deal. Now, if your SSD suddenly just dies, that’s a significantly bigger pain, because, on top of everything you have to do to replace another component, like RAM, you also have to reinstall the OS, and if you have any data that you have not yet backed up, that’s gone, too.

That’s why, to me at least, it’s worth spending a bit more on a quality SSD and minimise my chance of going through that whole process any time soon. Eventually, all hardware fails, of course, so I am prepared for it, but I’d rather have it happen later than sooner.

1 Like

Can you elaborate on that a bit? What exactly do you mean? Do you have links resp. references?

Yes, that seems strange.
Also the package was last updated 2018-06-22 and is flagged out-of-date.
Frankly, I never looked at this one before. The one I used at some point before, finding a reference to it in an article I read somewhere, is profile-sync-daemon.
I don’t have it now on my current install but I recall it worked rather satisfactorily.

before i hoped to EOS, i was MX Linux user for many years. Recently i bought a Kingston SSD and hence i had a concern regarding the partition schemes. this is what they had to say on SSD / Kernel tuning.
I bet other modern / major distros do such things.

I placed a script in /etc/profile.d which remaps the whole .cache folder to my ramdisk.

# Make X programs like chromium/firefox remap cache directory to ramdisk

if [ $USER ]; then
  export XDG_CACHE_HOME="/home/chomsky/ramdisk/${USER}/.cache"