SSDs on Linux — What I did not know
I am fairly new to the SSD game, and I, thus far, the only computer of mine with an SSD is the IBM T60 which I have written a couple of blog posts of previously. Therefore, I was not aware of a few — or, indeed, any — of the quirks that accompany the usage of an SSD and would hence like to quickly explore which settings I have changed in order to increase the life span of my SSD.
When I first learnt about the fact that SSDs apparently have a finite write-cycles, I was immediately surprised; I was honestly not aware of the fact that one can only write a certain number of GBs onto the drive before it either becomes read-only or fails entirely. Yet, as it turns out, the amount of data that you are required to write to the drive daily is so enormous that it will most likely not affect me in any way.
Something of particular importance to a machine such as my IBM T60 is the swap file, as the maximum RAM one is able to install hereinto is a mere 3 GB — or, rather, one can install 4 GB, whereof only 3 GB can be addressed by the chipset. Therefore, the usage of a swap file mitigates the problem of not having RAM galore, as it uses a portion of the SSD / HDD as its RAM; and this is where using an SSD is both an advantage and a disadvantage at the same time.
As SSDs tend to be much more nimble than HDDs, the swap file itself will have a noticeably increased speed as well; yet, at the same time, due to the finite write-cycles of SSDs, they may fail more rapidly when containing a swap file, as this increases the amount of data written to the drive significantly.
However, as it turns out, I should not concern myself greatly with this, for, as mentioned earlier, the amount of data that needs to be written to the drive for it to fail is large; so large, in fact, that a sizeable number of drives will not fail unless they have exceeded 1 Petabyte of data being written to them.
Hence, I will not be disabling my swap file, as it helps considerably on a machine with a mere 3 GB of RAM. Should you, however, want your SSD to lead as long a life as possible — and have enough RAM at your disposal —, I would recommend disabling the swap file.
An additional quirk of SSDs is that they handle overwriting existing data in a much different fashion than HDDs do; whereas with HDDs the data can be quite simply overwritten, SSDs are required to first erase the data contained on the block that you wish to write to. This leads to the slowing-down of the SSD over-time — something you obviously do not wish to happen.
TRIM, then, is a command that can be executed either whenever a file is deleted or on a scheduled basis — which, usually, is weekly — which deletes all the sectors marked by the OS as not being currently used, yet still containing data — i.e. those sectors containing data the user has deleted.
TRIM on Linux
Linux has natively supported TRIM since around 2010 and should, therefore, have the ability to handle SSDs with ease. Unfortunately, however, many Linux distributions do not have TRIM support enabled by default; and, apparently, neither did my Manjaro installation. Let us thus briefly explore the different possibilities of TRIMing your SSD.
The manual way
If you wish, you can TRIM your drive manually using the
fstrim command, to which you need to append a
-v flag and the root file system, i.e.
/, yielding the following command:
fstrim -v /. Upon running the command, you should be greeted by something similar to the following:
/: 2.8 GiB (2946961408 bytes) trimmed.
Depending on the amount of time which has passed since the previous TRIM, and the size of the drive, this may take a while; for example, upon my first execution of the above command, I was required to wait for nearly a minute, whereas from then on it has taken mere seconds.
The automatic way
Obviously, having to manually run the
fstrim command would be rather annoying, and the majority of people would much prefer having an automatic method to help them; luckily, a systemd service exists for such a purpose.
But prior to enabling said service, one should check that the so-called continous TRIM has not yet been enabled; this, it appears, is not recommended — why, exactly, I am unsure — and using a scheduled TRIM is generally preferred. Therefore, open
/etc/fstab in your preferred text editor and check that your current file system does not have the
discard option anywhere. Mine looks as follows: —
/dev/sda2 ext4 rw,noatime,nodelalloc,data=journal 0 0
Upon having ensured that continuous TRIMing has not been enabled, you can enable the
fstrim.timer service by typing the following: —
sudo systemctl enable fstrim.timer sudo systemctl start fstrim.timer
These two commands will both guarantee that the service will be started upon boot and that it will be enabled right now. Thereafter, TRIM should run about once a week and you will no longer have to worry about manually running a TRIM.
All in all, I am more than satisfied with my SSD and I will most likely install some SSDs into my other computers as well; nevertheless, they appear to harbour their own unique quirks one must be on the lookout for.